From apache@ticket.ietf.org Tue Oct 30 15:11:09 2007 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.2 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from ticket.ietf.org (ticket.ietf.ORG [156.154.16.147]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9UMAIgA016723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 30 Oct 2007 15:10:19 -0700 (PDT) Received: from apache by ticket.ietf.org with local (Exim 4.43) id 1ImzHu-0005Yi-2C for rfc-editor@rfc-editor.org; Tue, 30 Oct 2007 18:10:18 -0400 From: "IETF-IESG-Support via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: Message-ID: Precedence: bulk X-RT-Loop-Prevention: Inquiry RT-Ticket: Inquiry #97698 Managed-by: RT 3.2.1 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Tue, 30 Oct 2007 18:10:18 -0400 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: apache@ticket.ietf.org Subject: [Inquiry #97698] AutoReply: Informational (IRTF) Independent Submission: draft-irtf-tmrg-metrics-11.txt X-IMAPbase: 1225308294 98 $NotJunk $Junk Status: O X-Status: X-Keywords: $NotJunk X-UID: 1 Greetings, This message has been automatically generated in response to the creation of a ticket regarding: "Informational (IRTF) Independent Submission: draft-irtf-tmrg-metrics-11.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [Inquiry #97698] in the queue: IETF-IESG-Support. Please include the string: [Inquiry #97698] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- IESG, This RFC-to-be was submitted to the RFC Editor to be published as Informational: draft-irtf-tmrg-metrics-11.txt Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Four week timeout expires on 26 November 2007. Metrics for the Evaluation of Congestion Control Mechanisms This document discusses the metrics to be considered in an evaluation of new or modified congestion control mechanisms for the Internet. These include metrics for the evaluation of new transport protocols, of proposed modifications to TCP, of application-level congestion control, and of Active Queue Management (AQM) mechanisms in the router. This document is the first in a series of documents aimed at improving the models that we use in the evaluation of transport protocols. This document is a product of the Transport Modeling Research Group (TMRG), and has received detailed feedback from many members of the Research Group (RG). As the document tries to make clear, there is not necessarily a consensus within the research community (or the IETF community, the vendor community, the operations community, or any other community) about the metrics that congestion control mechanisms should be designed to optimize, in terms of tradeoffs between throughput and delay, fairness between competing flows, and the like. However, we believe that there is a clear consensus that congestion control mechanisms should be evaluated in terms of tradeoffs between a range of metrics, rather than in terms of optimizing for a single metric. Note: Please see the email below for more details regarding the review that this document has received. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents On Tue, Oct 23, 2007 at 09:22:38PM -0400, Aaron Falk wrote: > Dear RFC Editor- > > Please publish draft-irtf-tmrg-metrics-11 as an Informational IRTF- > stream RFC. The IRSG has reviewed this document and approved it for > publication. Please include Sally Floyd on all > correspondence relating to publication of this document. Details of > the review process follow below. > > --Aaron Falk > IRTF Chair > > > Begin forwarded message: > > >From: Sally Floyd > >Date: October 23, 2007 8:21:42 PM EDT > >To: Aaron Falk , Internet Research Steering Group > > > >Subject: TMRG metrics document ready to send to RFC editor > > > >Aaron - > > > >In accordance with current IRTF processes, the TMRG metrics > >document [1] is now finished IRSG review and ready for you > >to send to the RFC editor. > > > >The tracker ticket [2] for this has links to various stages of > >the review, including links to the June review from Tony Li [3] and > >feedback from Juergen Schoenwaelder [4]. The follow-up email [5] > >reports the Ready-to-Publish votes from Juergen Schoenwaelder and > >Aaron Falk, and the changes in the document to address the feedback > >received. Email from the RG can be found on the TMRG mailing list > >[6, 7, 8, 9, 10, 11]. > > > >I'll be shepherd for this document which is intended to become > >an informational RFC. > > > >[1] http://www.icir.org/tmrg/draft-irtf-tmrg-metrics-11.txt > > http://www.icir.org/tmrg/draft-irtf-tmrg-metrics-11.ps > >[2] http://www1.tools.ietf.org/group/irtf/trac/ticket/11 > >[3] http://mailman.icsi.berkeley.edu/pipermail/tmrg-interest/2007- > >June/000150.html > >[4] http://www3.tools.ietf.org/group/irtf/trac/attachment/ticket/11/ > >Schoenwaelder-review.txt > >[5] http://www3.tools.ietf.org/group/irtf/trac/attachment/ticket/11/ > >Floyd-Oct-3-2007.txt > >[6] http://mailman.icsi.berkeley.edu/pipermail/tmrg-interest/2006- > >November/000133.html > >[7] http://mailman.icsi.berkeley.edu/pipermail/tmrg-interest/2007- > >February/000135.html > >[8] http://mailman.icsi.berkeley.edu/pipermail/tmrg-interest/2007- > >March/000138.html > >[9] http://mailman.icsi.berkeley.edu/pipermail/tmrg-interest/2007- > >March/000141.html > >[10] http://mailman.icsi.berkeley.edu/pipermail/tmrg-interest/2007- > >September/000166.html > >[11] http://mailman.icsi.berkeley.edu/pipermail/tmrg-interest/2007- > >September/000188.html > > > >Regards, > >- Sally > >http://www.icir.org/floyd/ > > From apache@ticket.ietf.org Thu Nov 8 12:52:20 2007 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.2 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from ticket.ietf.org (stiedprtick1.ietf.ORG [156.154.16.147]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lA8Kpnam012522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 8 Nov 2007 12:51:49 -0800 (PST) Received: from apache by ticket.ietf.org with local (Exim 4.43) id 1IqELs-0008ON-Hl for rfc-editor@rfc-editor.org; Thu, 08 Nov 2007 15:51:48 -0500 From: "IETF-IESG-Support via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: Message-ID: Precedence: bulk X-RT-Loop-Prevention: Inquiry RT-Ticket: Inquiry #97880 Managed-by: RT 3.2.1 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Thu, 08 Nov 2007 15:51:48 -0500 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: apache@ticket.ietf.org Subject: [Inquiry #97880] AutoReply: Informational Independent Submission: draft-jayasumana-reorder-density-07.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 2 Greetings, This message has been automatically generated in response to the creation of a ticket regarding: "Informational Independent Submission: draft-jayasumana-reorder-density-07.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [Inquiry #97880] in the queue: IETF-IESG-Support. Please include the string: [Inquiry #97880] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- IESG, This RFC-to-be was submitted to the RFC Editor to be published as Informational: draft-jayasumana-reorder-density-07.txt. Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Five week timeout expires on 13 December 2007. We have included an additional week because of the upcoming IETF. Reorder Density and Reorder Buffer-occupancy Density - Metrics for Packet Reordering Measurements This document presents two metrics for packet reordering, namely, Reorder Density (RD) and Reorder Buffer-occupancy Density (RBD). A threshold is used to clearly define when a packet is considered lost, to bound computational complexity at O(N), and to keep the memory requirement for evaluation independent of N, where N is the length of the packet sequence. RD is a comprehensive metric that captures the characteristics of reordering, while RBD evaluates the sequences from the point of view of recovery from reordering. These metrics are simple to compute yet comprehensive in their characterization of packet reordering. The measures are robust and orthogonal to packet loss and duplication. This document was reviewed by Craig Partridge (twice) and significantly updated as a result. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents From apache@ticket.ietf.org Wed Nov 21 14:37:14 2007 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.2 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from ticket.ietf.org (ticket.ietf.ORG [156.154.16.147]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lALMaFNp015522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 21 Nov 2007 14:36:16 -0800 (PST) Received: from apache by ticket.ietf.org with local (Exim 4.43) id 1IuyB5-000158-3l for rfc-editor@rfc-editor.org; Wed, 21 Nov 2007 17:36:15 -0500 From: "IETF-IESG-Support via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: Message-ID: Precedence: bulk X-RT-Loop-Prevention: Inquiry RT-Ticket: Inquiry #98125 Managed-by: RT 3.2.1 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Wed, 21 Nov 2007 17:36:15 -0500 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: apache@ticket.ietf.org Subject: [Inquiry #98125] AutoReply: Exerpimental (IRTF) Independent Submission: draft-irtf-mobopts-l2-abstractions-04.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 3 Greetings, This message has been automatically generated in response to the creation of a ticket regarding: "Exerpimental (IRTF) Independent Submission: draft-irtf-mobopts-l2-abstractions-04.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [Inquiry #98125] in the queue: IETF-IESG-Support. Please include the string: [Inquiry #98125] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- IESG, This RFC-to-be was submitted to the RFC Editor to be published as Experimental: draft-irtf-mobopts-l2-abstractions-04.txt. Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Five week timeout expires on 26 December 2007. (Note that this is a 5 week timeout because of the upcoming IETF.) Unified L2 Abstractions for L3-Driven Fast Handover This draft proposes unified L2 abstractions for L3-driven fast handovers. For efficient network communication, it is vital for a protocol layer to know or utilize other layer's information such as a form of L2 triggers. However, each protocol layer is basically designed independently. Since each protocol layer is also implemented independently in current operating systems, it is very hard to exchange control information between protocol layers. This draft defines nine kinds of L2 abstractions in the form of "primitives" to achieve fast handovers in the network layer as a means of solving the problem. This mechanism is called "L3-driven fast handovers" because the network layer initiates L2 and L3 handovers by using the "primitives". This document is a product of the IP Mobility Optimizations (MobOpts) Research Group. Please note that the email below provides additional information about the review this document has received. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents ----- Forwarded message from Aaron Falk ----- Cc: Internet Research Steering Group , Rajeev Koodli , mobopts@irtf.org From: Aaron Falk Subject: Request to publish draft-irtf-mobopts-l2-abstractions-04 as an IRTF RFC Date: Wed, 21 Nov 2007 10:23:52 -0500 To: RFC Editor Dear RFC Editor- Please publish draft-irtf-mobopts-l2-abstractions-04 as an Experimental IRTF-stream RFC. The IRSG has reviewed this document and approved it for publication. Please include Rajeev Koodli on all correspondence relating to publication of this document. Details of the review process follow below. Also, please make the two small edits are requested below. Regards, --Aaron Falk IRTF Chair Begin forwarded message: >From: Rajeev Koodli >Date: November 20, 2007 8:53:41 PM EST >To: ext Aaron Falk >Cc: , "mobopts@irtf.org" >Subject: IRSG review of draft-irtf-mobopts-l2-abstractions-04.txt >completed > > >Hi Aaron, > >This note is to formally request you to advance the MobOpts RG ID >"Unified >L2 Abstractions for L3-Driven fast Handover" [1] to IESG for their "no >circumvention" review prior to its publication as an Experimental RFC. > >The detailed IRSG review (of version 03) and subsequent acceptance (of >version 04) by John Levine are available at > >http://www1.ietf.org/mail-archive/web/mobopts/current/msg00873.html > >The above review and the IRSG poll input are documented at the tracker >http://www3.tools.ietf.org/group/irtf/trac (which is currently down >for me >to provide the exact ticket #) > >Since this document represents the consensus of the MobOpts RG, I >request >that the following IESG note (taken from [2]) be included: > >"This document is not an IETF Internet Standard. It represents >the consensus of the MobOpts Research Group of the Internet Research >Task Force. It may be considered for standardization by the >IETF in the future." > >The IRSG poll provided input [3] which could be incorporated as RFC >Editor >notes. > >Thanks, > >-Rajeev >-- >http://people.nokia.net/~rajeev > > > > >[1]: http://tools.ietf.org/id/draft-irtf-mobopts-l2- >abstractions-04.txt > >[2]: http://www.irtf.org/chairfiles/draft-irtf-rfcs-01.html#iesg-notes > >[3]: >> >>Vote: Ready to publish >> >>Short Review: >> >>The document is very easy to read and understand. I have worked >>in this >>area (though more focused on L3-L4 interaction than L3-L2) and I >>think it >>is a useful and needed contribution. >> >>The diagrams are clear and the appendices provide useful supporting >>material. >> >>The "Architectural Considerations" section is a good idea for a >>document >>like this, and building off the IAB document was also a great idea. >> >>I didn't quite buy the logic on number 5, and suggest a different >>explanation >>instead of: >>> [5] Proposals must demonstrate that effective congestion >>>control is >>> maintained. >>> >>> Since this mechanism is coupled to the IP layer, and not >>> directly to the transport layer, the proposed mechanism does >>> not directly affect congestion control. >> >>I think it would be more correct to say: >>Since the proposed inter-layer communications are local within a >>host, >>and not across a network, they don't directly raise congestion >>control >>concerns. The response of individual protocols to these >>notifications >>should ensure that effective congestion control is maintained, but >>those >>instantiations are outside the scope of this document. >> >>Grammar/Spelling: >> >>"utilize other layer's control" -> >>"utilize other layers' control" ? > > > ----- End forwarded message ----- From apache@ticket.ietf.org Mon Dec 10 14:57:22 2007 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.2 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from ticket.ietf.org (stiedprtick1.ietf.ORG [156.154.16.147]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lBAMut6M004865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 10 Dec 2007 14:56:57 -0800 (PST) Received: from apache by ticket.ietf.org with local (Exim 4.43) id 1J1rYV-0007QP-6S for rfc-editor@rfc-editor.org; Mon, 10 Dec 2007 17:56:55 -0500 From: "IETF-IESG-Support via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: Message-ID: Precedence: bulk X-RT-Loop-Prevention: Inquiry RT-Ticket: Inquiry #98415 Managed-by: RT 3.2.1 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Mon, 10 Dec 2007 17:56:55 -0500 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: apache@ticket.ietf.org Subject: [Inquiry #98415] AutoReply: Informational Independent Submission: draft-levis-provider-qos-agreement-04.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 4 Greetings, This message has been automatically generated in response to the creation of a ticket regarding: "Informational Independent Submission: draft-levis-provider-qos-agreement-04.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [Inquiry #98415] in the queue: IETF-IESG-Support. Please include the string: [Inquiry #98415] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- IESG, This RFC-to-be was submitted to the RFC Editor to be published as Informational: draft-levis-provider-qos-agreement-04.txt. Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Five week timeout expires on 14 January 2007. Please note that we have included an additional week because of the coming holidays. Considerations of provider-to-provider agreements for Internet-scale QoS This memo analyzes provider-to-provider QoS agreements suitable for a global QoS-enabled Internet. It defines terminology relevant to inter-domain QoS models. It proposes a new concept denoted by Meta-QoS-Class (MQC). This concept could potentially drive and federate the way QoS inter-domain relationships are built between providers. It opens up new perspectives for a QoS-enabled Internet that retains, as much as possible, the openness of the existing best-effort Internet. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents From apache@ticket.ietf.org Wed Jan 2 18:57:14 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-1.8 required=4.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from ticket.ietf.org (stiedprtick1.ietf.ORG [156.154.16.147]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m032uEfh009033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 2 Jan 2008 18:56:16 -0800 (PST) Received: from apache by ticket.ietf.org with local (Exim 4.43) id 1JAGFi-0000eo-HQ for rfc-editor@rfc-editor.org; Wed, 02 Jan 2008 21:56:14 -0500 From: "IETF-IESG-Support via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: Message-ID: Precedence: bulk X-RT-Loop-Prevention: Inquiry RT-Ticket: Inquiry #98639 Managed-by: RT 3.2.1 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Wed, 02 Jan 2008 21:56:14 -0500 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: apache@ticket.ietf.org Subject: [Inquiry #98639] AutoReply: Re: Document Action: 'Session Initiation Protocol (SIP) Session Mobility' to Informational RFC Status: O X-Status: X-Keywords: $NotJunk X-UID: 5 Greetings, This message has been automatically generated in response to the creation of a ticket regarding: "Re: Document Action: 'Session Initiation Protocol (SIP) Session Mobility' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [Inquiry #98639] in the queue: IETF-IESG-Support. Please include the string: [Inquiry #98639] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Wed, Jan 02, 2008 at 04:27:41PM -0500, The IESG wrote: > The IESG has approved the following document: > > - 'Session Initiation Protocol (SIP) Session Mobility ' > as an Informational RFC > > This document has been reviewed in the IETF but is not the product of an > IETF Working Group. > > The IESG contact person is Jon Peterson. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-shacham-sipping-session-mobility-05.txt > > Technical Summary > > This document specifies a method in which media flows can migrate between > SIP devices in order to enable session mobility. The Service Location > Protocol is employed to locate targets for session transfer. > > Working Group Summary > > This document is an individual submission, but the SIPPING working group > was an early venue for its discussion. > > Protocol Quality > > This document was reviewed for the IESG by Jon Peterson. Francis Dupont > was the Gen-ART reviewer. Pete McCann reviewed this document for the > Mobility Directorate. From apache@ticket.ietf.org Wed Jan 2 18:57:17 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-1.8 required=4.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from ticket.ietf.org (stiedprtick1.ietf.ORG [156.154.16.147]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m032tnG8008820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 2 Jan 2008 18:55:50 -0800 (PST) Received: from apache by ticket.ietf.org with local (Exim 4.43) id 1JAGFI-0000eM-Pr for rfc-editor@rfc-editor.org; Wed, 02 Jan 2008 21:55:48 -0500 From: "IETF-IESG-Support via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: Message-ID: Precedence: bulk X-RT-Loop-Prevention: Inquiry RT-Ticket: Inquiry #98638 Managed-by: RT 3.2.1 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Wed, 02 Jan 2008 21:55:48 -0500 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: apache@ticket.ietf.org Subject: [Inquiry #98638] AutoReply: Re: Protocol Action: 'Revised Civic Location Format for PIDF-LO' to Proposed Standard Status: O X-Status: X-Keywords: $NotJunk X-UID: 6 Greetings, This message has been automatically generated in response to the creation of a ticket regarding: "Re: Protocol Action: 'Revised Civic Location Format for PIDF-LO' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [Inquiry #98638] in the queue: IETF-IESG-Support. Please include the string: [Inquiry #98638] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Wed, Jan 02, 2008 at 04:22:43PM -0500, The IESG wrote: > The IESG has approved the following document: > > - 'Revised Civic Location Format for PIDF-LO ' > as a Proposed Standard > > This document is the product of the Geographic Location/Privacy Working > Group. > > The IESG contact persons are Cullen Jennings. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-revised-civic-lo-07.txt > > Technical Summary > > This document defines an XML format for the representation of civic > location. This format is designed for use with PIDF Location Object > (PIDF-LO) documents. The format is based on the civic address > definition in PIDF-LO, but adds several new elements based on the > civic types defined for DHCP, and adds a hierarchy to address complex > road identity schemes. The format also includes support for the > xml:lang language tag and restricts the types of elements where > appropriate. > > > Working Group Summary > > This document was reviewed by the GEOPRIV working group, where it > has reached consensus for publication as an IETF RFC. > > > Document Quality > > The XML Schema contained within this document has been checked > against Xerces-J 2.6.2. > > In addition to updating RFC 4119, this document is also a normative > reference in draft-ietf-ecrit-lost-05.txt. > > There are three known implementations of this specification. > > > Personnel > > The Document Shepherd is Robert Sparks. > The Responsible Area Director is Cullen Jennings. From apache@ticket.ietf.org Wed Jan 2 18:57:19 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-1.8 required=4.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from ticket.ietf.org (stiedprtick1.ietf.ORG [156.154.16.147]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m032tjRI008778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 2 Jan 2008 18:55:46 -0800 (PST) Received: from apache by ticket.ietf.org with local (Exim 4.43) id 1JAGFF-0000e2-8Y for rfc-editor@rfc-editor.org; Wed, 02 Jan 2008 21:55:45 -0500 From: "IETF-IESG-Support via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: Message-ID: Precedence: bulk X-RT-Loop-Prevention: Inquiry RT-Ticket: Inquiry #98637 Managed-by: RT 3.2.1 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Wed, 02 Jan 2008 21:55:45 -0500 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: apache@ticket.ietf.org Subject: [Inquiry #98637] AutoReply: Re: Protocol Action: 'RTP payload format for Enhanced Variable Rate Wideband Codec (EVRC-WB) and media subtype updates for EVRC-B codec' to Proposed Standard Status: O X-Status: X-Keywords: $NotJunk X-UID: 7 Greetings, This message has been automatically generated in response to the creation of a ticket regarding: "Re: Protocol Action: 'RTP payload format for Enhanced Variable Rate Wideband Codec (EVRC-WB) and media subtype updates for EVRC-B codec' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [Inquiry #98637] in the queue: IETF-IESG-Support. Please include the string: [Inquiry #98637] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Wed, Jan 02, 2008 at 04:11:11PM -0500, The IESG wrote: > The IESG has approved the following document: > > - 'RTP payload format for Enhanced Variable Rate Wideband Codec > (EVRC-WB) and media subtype updates for EVRC-B codec ' > as a Proposed Standard > > This document is the product of the Audio/Video Transport Working Group. > > > The IESG contact persons is Cullen Jennings. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-evrc-wb-09.txt > > Technical Summary > > This document specifies real-time transport protocol (RTP) payload > formats to be used for the EVRC wideband codec (EVRC-WB) and updates the > media type registrations for EVRC-B codec (RFC 4788). Several media type > registrations are included for EVRC-WB RTP payload formats. In addition, a > file format is specified for transport of EVRC-WB speech data in storage > mode applications such as e-mail. > > > Working Group Summary > > The document has been reviewed by the AVT working group to ensure > consistency with RFC 4788 media type registration, and meets the necessary > requirements to for payload type specification. > > > Document Quality > > The draft has existing implementation and is required for 3GPP2. The > request for review of the media type in the ietf-type list was posted on > May 24, 2007. > > > Personnel > > Roni Even is the document shepherd. From apache@ticket.ietf.org Wed Jan 2 18:57:22 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-1.8 required=4.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from ticket.ietf.org (stiedprtick1.ietf.ORG [156.154.16.147]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m032uH1n009065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 2 Jan 2008 18:56:18 -0800 (PST) Received: from apache by ticket.ietf.org with local (Exim 4.43) id 1JAGFl-0000ey-0d for rfc-editor@rfc-editor.org; Wed, 02 Jan 2008 21:56:17 -0500 From: "IETF-IESG-Support via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: Message-ID: Precedence: bulk X-RT-Loop-Prevention: Inquiry RT-Ticket: Inquiry #98640 Managed-by: RT 3.2.1 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Wed, 02 Jan 2008 21:56:17 -0500 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: apache@ticket.ietf.org Subject: [Inquiry #98640] AutoReply: Re: Document Action: 'Mobility Services Transport: Problem Statement' to Informational RFC Status: O X-Status: X-Keywords: $NotJunk X-UID: 8 Greetings, This message has been automatically generated in response to the creation of a ticket regarding: "Re: Document Action: 'Mobility Services Transport: Problem Statement' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [Inquiry #98640] in the queue: IETF-IESG-Support. Please include the string: [Inquiry #98640] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Wed, Jan 02, 2008 at 04:33:55PM -0500, The IESG wrote: > The IESG has approved the following document: > > - 'Mobility Services Transport: Problem Statement ' > as an Informational RFC > > This document is the product of the Mobility for IP: Performance, > Signaling and Handoff Optimization Working Group. > > The IESG contact persons are Jari Arkko and Mark Townsley. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mipshop-mis-ps-05.txt > > Technical Summary > > The document provides a problem statement for the exchange of > information to support handover in heterogeneous link environments. > This mobility support service allows more sophisticated handover > operations by making available information about network > characteristics, neighboring networks and associated characteristics, > indications that a handover should take place, and suggestions for > suitable target networks to which to handover. The mobility support > services work complementarily with IP mobility mechanisms to enhance > the overall performance and usability perception. > > Working Group Summary > > This is a product of the MIPSHOP WG. > > Protocol Quality > > The draft has been reviewed by numerous folks, including folks > who are proficient in transport and mobility. This document went > through a WG last call in the MIPSHOP WG. The document captures > the issues to be addressed in the MIPSHOP WG work for implementing > a transport for the IEEE 802.21 services. As such, the document > has also been reviewed by the IEEE 802.21 liaison and many of > their members. > > Jari Arkko has reviewed this specification for the IESG. Gorry > Fairhurst provided a transport review. > > Note to RFC Editor > > Remove annex and adding the following sentence in > Section 1: > > Requirements to support 802.21 by L3 and above transport are > described in [1] (work in progress). > > Please change in Section 5.2: > OLD: > A common security association negotiation method, independent > of any specific MSTP user, should be implemented. > NEW: > A common security association negotiation method, independent > of any specific MSTP user, should be implemented between the endpoints > > > > > of the MSTP. > > Please correct the following: On page 8: > /other standards bodies other than the IETF/ > ^^^^^ > - remove "other" > > On page 11 > /arrive at a rate of hundreds of milliseconds/ > - It should be "at an interval of hundreds of milliseconds". > > On page 11 > / to around 65000 bytes/ > ^^^^^^ > - Should be: to be normally less than 64KB, but may be greater than 64 > KB > > On page 15 > /TR2.The transport protocol shall be capable to support both IPv4 > and IPv6 versions/ > /TR2.The transport protocol shall be able to operate over both the IPv4 > and IPv6 network layer/ From apache@ticket.ietf.org Wed Jan 2 18:57:30 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-1.8 required=4.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from ticket.ietf.org (stiedprtick1.ietf.ORG [156.154.16.147]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m032v7BJ009259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 2 Jan 2008 18:57:08 -0800 (PST) Received: from apache by ticket.ietf.org with local (Exim 4.43) id 1JAGGZ-0000fU-16 for rfc-editor@rfc-editor.org; Wed, 02 Jan 2008 21:57:07 -0500 From: "IETF-IESG-Support via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: Message-ID: Precedence: bulk X-RT-Loop-Prevention: Inquiry RT-Ticket: Inquiry #98641 Managed-by: RT 3.2.1 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Wed, 02 Jan 2008 21:57:07 -0500 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: apache@ticket.ietf.org Subject: [Inquiry #98641] AutoReply: Re: Document Action: 'A URN namespace for the Commission for the Management and Application of Geoscience Information (CGI)' to Informational RFC Status: O X-Status: X-Keywords: $Junk X-UID: 9 Greetings, This message has been automatically generated in response to the creation of a ticket regarding: "Re: Document Action: 'A URN namespace for the Commission for the Management and Application of Geoscience Information (CGI)' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [Inquiry #98641] in the queue: IETF-IESG-Support. Please include the string: [Inquiry #98641] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Wed, Jan 02, 2008 at 04:58:15PM -0500, The IESG wrote: > The IESG has approved the following document: > > - 'A URN namespace for the Commission for the Management and Application > of Geoscience Information (CGI) ' > as an Informational RFC > > This document has been reviewed in the IETF but is not the product of an > IETF Working Group. > > The IESG contact person is Lisa Dusseault. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-sjdcox-cgi-urn-00.txt > > Technical Summary > > This document registers the "cgi" URN NID for the Commission for the > Management and Application of > Geoscience Information (CGI) for naming (i) persistent resources > published by the CGI, and (ii) resources published by organizations > that wish them to be used in the context of services conforming to > protocols and agreements issued by CGI. > > Working Group Summary > > Not a WG doc. > > Protocol Quality > > Lisa Dusseault reviewed this document for the IESG. From apache@ticket.ietf.org Wed Jan 2 18:57:33 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-1.8 required=4.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from ticket.ietf.org (stiedprtick1.ietf.ORG [156.154.16.147]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m032vANt009274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 2 Jan 2008 18:57:11 -0800 (PST) Received: from apache by ticket.ietf.org with local (Exim 4.43) id 1JAGGb-0000fn-Bn for rfc-editor@rfc-editor.org; Wed, 02 Jan 2008 21:57:09 -0500 From: "IETF-IESG-Support via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: Message-ID: Precedence: bulk X-RT-Loop-Prevention: Inquiry RT-Ticket: Inquiry #98642 Managed-by: RT 3.2.1 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Wed, 02 Jan 2008 21:57:09 -0500 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: apache@ticket.ietf.org Subject: [Inquiry #98642] AutoReply: Re: Document Action: 'Service Selection for Mobile IPv6' to Informational RFC Status: O X-Status: X-Keywords: $Junk X-UID: 10 Greetings, This message has been automatically generated in response to the creation of a ticket regarding: "Re: Document Action: 'Service Selection for Mobile IPv6' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [Inquiry #98642] in the queue: IETF-IESG-Support. Please include the string: [Inquiry #98642] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Wed, Jan 02, 2008 at 04:35:40PM -0500, The IESG wrote: > The IESG has approved the following document: > > - 'Service Selection for Mobile IPv6 ' > as an Informational RFC > > This document has been reviewed in the IETF but is not the product of an > IETF Working Group. > > The IESG contact person is Jari Arkko. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-korhonen-mip6-service-06.txt > > Technical Summary > > This document describes a Service Selection Mobility Option for both > conventional Mobile IPv6 and Proxy Mobile IPv6 that is intended to > assist home agents to make a specific service selection for the > mobility service subscription during the binding update procedure. > introduction. The service selection may affect home agent routing > decisions, Qos and policy treatment of service related IP flows in the > home agent and also Home Address or Home Network Prefix assignment > policies. > > Working Group Summary > > This document is an individual submission. The document was > presented in MIP6 WG meetings and interest raised especially > from Proxy Mobile IPv6 deployment scenarios. The document was > proposed to be a WG work item. However, the decision of adoption > as a WG work item got postponed due time schedule challenges > with the current MIP6 WG charter. > > Document Quality > > There are no publicly known implementations yet. There is certain > level of interest from 3GPP SAE work to adopt the document as a > part of their architecture. > > Jari Arkko has reviewed this specification for the IESG. Based > on the AD review, a revised document was submitted. From apache@ticket.ietf.org Wed Jan 2 18:57:36 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-1.8 required=4.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from ticket.ietf.org (stiedprtick1.ietf.ORG [156.154.16.147]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m032vBhw009282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 2 Jan 2008 18:57:13 -0800 (PST) Received: from apache by ticket.ietf.org with local (Exim 4.43) id 1JAGGd-0000ft-EZ for rfc-editor@rfc-editor.org; Wed, 02 Jan 2008 21:57:11 -0500 From: "IETF-IESG-Support via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: Message-ID: Precedence: bulk X-RT-Loop-Prevention: Inquiry RT-Ticket: Inquiry #98643 Managed-by: RT 3.2.1 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Wed, 02 Jan 2008 21:57:11 -0500 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: apache@ticket.ietf.org Subject: [Inquiry #98643] AutoReply: Re: Document Action: 'A Uniform Resource Name (URN) Namespace for the International Organization for Standardization (ISO)' to Informational RFC Status: O X-Status: X-Keywords: $NotJunk X-UID: 11 Greetings, This message has been automatically generated in response to the creation of a ticket regarding: "Re: Document Action: 'A Uniform Resource Name (URN) Namespace for the International Organization for Standardization (ISO)' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [Inquiry #98643] in the queue: IETF-IESG-Support. Please include the string: [Inquiry #98643] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Wed, Jan 02, 2008 at 05:00:17PM -0500, The IESG wrote: > The IESG has approved the following document: > > - 'A Uniform Resource Name (URN) Namespace for the International > Organization for Standardization (ISO) ' > as an Informational RFC > > This document has been reviewed in the IETF but is not the product of an > IETF Working Group. > > The IESG contact person is Lisa Dusseault. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-goodwin-iso-urn-03.txt > > Technical Summary > > This document describes a Uniform Resource Name Namespace > Identification (URN NID) for the International Organization for > Standardization (ISO). This URN NID is intended for use for the > identification of persistent resources published by the ISO standards > body (including documents, document metadata, extracted resources > such as standard schemata and standard value sets, and other > resources).(What does this protocol do and why does the community need > it?) > > Working Group Summary > > This is the product of an individual submitter; it was reviewed on > urn-nid list as required, and no issues were found. > > Protocol Quality > > This document was reviewed by Ted Hardie and Lisa Dusseault for the IESG. > > Radia Perlman was the SecDir reviewer and Eric Gray was the GenArt > reviewer. Frank Ellerman reviewed the doc including the ABNF. > > Note to RFC Editor > > The proposed status is Informational -- please make sure the document > gets published as Informational as it says in the tracker, not as Proposed > Standard as it says in the document. From apache@ticket.ietf.org Fri Jan 11 16:03:05 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-1.8 required=4.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from ticket.ietf.org (ticket.ietf.ORG [156.154.16.147]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0C026Il025863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 11 Jan 2008 16:02:08 -0800 (PST) Received: from apache by ticket.ietf.org with local (Exim 4.43) id 1JDTp8-00033Y-Gu for rfc-editor@rfc-editor.org; Fri, 11 Jan 2008 19:02:06 -0500 From: "IETF-IESG-Support via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: Message-ID: Precedence: bulk X-RT-Loop-Prevention: Inquiry RT-Ticket: Inquiry #98764 Managed-by: RT 3.2.1 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Fri, 11 Jan 2008 19:02:06 -0500 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: apache@ticket.ietf.org Subject: [Inquiry #98764] AutoReply: Re: Protocol Action: 'Hash Based Addresses (HBA)' to Proposed Standard Status: O X-Status: X-Keywords: $NotJunk X-UID: 12 Greetings, This message has been automatically generated in response to the creation of a ticket regarding: "Re: Protocol Action: 'Hash Based Addresses (HBA)' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [Inquiry #98764] in the queue: IETF-IESG-Support. Please include the string: [Inquiry #98764] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Fri, Jan 11, 2008 at 04:29:18PM -0500, The IESG wrote: > The IESG has approved the following document: > > - 'Hash Based Addresses (HBA) ' > as a Proposed Standard > > This document is the product of the Site Multihoming by IPv6 > Intermediation Working Group. > > The IESG contact persons are Jari Arkko and Mark Townsley. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-05.txt > > Technical Summary > > Hash Based Addresses are intended to provide a secure binding > between the multiple addresses with different prefixes available > to a host within a multihomed site. Information about the > multiple prefixes is included within the addresses by generating > the interface identifiers of the addresses of a host as hashes of > the set of available prefixes and a random number, which are then > appended to the the different prefixes. The result is a set of > addresses that are inherently bound together such that given one > valid address out of the group, the prefix set and the random > number, it is possible to determine whether another address is > part of the group by computing the hash and checking against the > interface identifier value. > > Working Group Summary > > The document has extensively reviewed by the Working Group and by > the Security Area Directorate. The Working Group consensus was to > recommend publication of this document as a Proposed Standard. > > Protocol Quality > > Jari Arkko has reviewed this specification for the IESG. > > There are known implementations of this specification, and there > have been no implemtation experiences that have implied any > further revision to this specification is required. > > Note to RFC Editor > > Please add a new subsection: > > 11.x.DoS attacks considerations > > In order to use the HBA technique, the owner of the HBA set must inform > about the CGA Parameter Data Structure to its peer in order to allow the > peer to verify tat the different HBAs belong to the same HBA set. Such > information must then be stored by the peer to verify alternative > addresses in the future. This can be a vector for DoS attacks, since the > peer must commit resources (in this particular case memory) to be able to > use the HBA technique for address verification. It is then possible for an > attacker to launch a DoS attack by conveying HBA information to a victim, > imposing the victim to use memory for storing HBA related state, and > eventually running out of memory for other genuine operations. In order to > prevent such attack, protocols that use the HBA technique should implement > proper DoS prevention techniques. For instance, the Shim6 protocol > (draft-ietf-shim6-proto] includes a 4-way handshake to establish the Shim6 > context and in particular to establish the HBA-related state. In this > 4-way handshake, the receiver remains stateless during the first 2 > messages, while the initiator must keep state throughout the exchange of > the 4 messages, so that the cost of the context establishment is higher in > memory terms for the initiator (i.e. the potential attacker) than for the > receiver (i.e. the potential victim). In addition to that, the 4-way > handshake, prevents the usage of spoofed addresses from off-path attacker, > since the initiator must be able to receive information through the > address it has used as source address, enabling the tracking of the > location from which the attack was launched from. From root@core3.amsl.com Thu Feb 21 18:45:23 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.0 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m1M2iwc1012677 for ; Thu, 21 Feb 2008 18:44:59 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 0) id B1F923A6839; Thu, 21 Feb 2008 18:45:01 -0800 (PST) Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: rfc-editor@rfc-editor.org Cc: iesg@ietf.org From: IESG Secretary Message-Id: <20080222024501.B1F923A6839@core3.amsl.com> Date: Thu, 21 Feb 2008 18:45:01 -0800 (PST) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: root@core3.amsl.com Subject: Regarding draft-ietf-smime-symkeydist-10.txt Status: O X-Status: X-Keywords: $Junk X-UID: 13 Subject: draft-ietf-smime-symkeydist-10.txt This document has been in the RFC Editor queue since February 2003. It has been waiting on a normative dependency on draft-ietf-pkix-2797-bis. That document is finally close to publication -- just two more IESG DISCUSS positions to resolve. Some things have changed in the five years that this document has been waiting, so the author just posted an update to align the two documents. Considering the time that has passed, the changes are very few. Please accept this update, and treat these changes similar to Auth48 changes. The IESG has reviewed them, and they do not require further review. For more background information, please see the trail below: Date: Mon, 3 Dec 2007 11:48:35 -0800 From: RFC Editor To: IESG Cc: kfall@cs.berkeley.edu, RFC Editor Subject: RFC database: additional information regarding GRE RFC's IESG, We received this inquiry below about the relationships between some GRE RFCs. Do you have any input on whether RFC 1701 should be updated/obsoleted by RFC 2784? Thanks, Sandy ----- Forwarded message from Kevin Fall ----- To: rfc-editor@rfc-editor.org From: Kevin Fall Subject: RFC database: additional information regarding GRE RFC's Date: Sat, 17 Nov 2007 15:28:48 -0800 Hi. I was going through the RFC search tool and noticed that the Obsoletes/Updates field for some of the GRE-related RFCs appear to be missing. In particular, I would have expected 1701 to be listed as updated (obsoleted?) by 2784, which in turn is updated by 2890. Do I have this correct? thx, - Kevin ----- End forwarded message ----- At 12:18 PM 2/21/2008, Mark Townsley wrote: >Secretary, > >Please clarify to the RFC Editor that: > >RFC 2890 updates RFC 2784. Neither are an update of RFC 1701 or 1702. > >RFC 1702 is not supposed to be an update of 1701, it's supposed to >be an orthogonal and complementary document. > >Thank you, > >- Mark > From wwwrun@core3.amsl.com Mon Feb 25 13:55:49 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m1PLsH3b006191 for ; Mon, 25 Feb 2008 13:54:17 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id C881428CAE8; Mon, 25 Feb 2008 13:42:09 -0800 (PST) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080225212907.GE8375@isi.edu> References: <20080221223001.C680C3A6C66@core3.amsl.com> <20080225212907.GE8375@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #2483 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Mon, 25 Feb 2008 13:42:09 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #2483] AutoReply: Re: draft-ietf-smime-symkeydist-10.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 14 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: draft-ietf-smime-symkeydist-10.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #2483]. Please include the string: [rt.amsl.com #2483] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- Greetings IESG Secretariat, It looks like 2 messages got crossed here. We have updated our queue to reflect v10 for draft-ietf-smime-symkeydist-10.txt and we will use v10 as our starting point for publication. However, the message states "For more background information, please see the trail below:", but the mail messages below are about the relationship between RFCs 1701, 2784, and 2890. Could you please resend the messages (i.e., the one with the appropriate trail information for draft-ietf-smime-symkeydist-10.txt and the response to the relation between RFCs 1701, 2784, and 2890)? Thanks! Sandy On Thu, Feb 21, 2008 at 02:30:01PM -0800, The IESG wrote: > Subject: draft-ietf-smime-symkeydist-10.txt > > This document has been in the RFC Editor queue since February > 2003. It has been waiting on a normative dependency on > draft-ietf-pkix-2797-bis. That document is finally close to > publication -- just two more IESG DISCUSS positions to resolve. Some > things have changed in the five years that this document has been > waiting, so the author just posted an update to align the two > documents. Considering the time that has passed, the changes are > very few. Please accept this update, and treat these changes similar > to Auth48 changes. The IESG has reviewed them, and they do not > require further review. > > For more background information, please see the trail below: > > Date: Mon, 3 Dec 2007 11:48:35 -0800 > From: RFC Editor > To: IESG > Cc: kfall@cs.berkeley.edu, RFC Editor > Subject: RFC database: additional information regarding GRE RFC's > > IESG, > > We received this inquiry below about the relationships between some > GRE RFCs. Do you have any input on whether RFC 1701 should be > updated/obsoleted by RFC 2784? > > Thanks, > Sandy > > ----- Forwarded message from Kevin Fall ----- > > To: rfc-editor@rfc-editor.org > From: Kevin Fall > Subject: RFC database: additional information regarding GRE RFC's > Date: Sat, 17 Nov 2007 15:28:48 -0800 > > > Hi. > > I was going through the RFC search tool and noticed that the > Obsoletes/Updates field for some of the GRE-related RFCs appear to be > missing. > > In particular, I would have expected 1701 to be listed as updated > (obsoleted?) by 2784, which in turn is updated by 2890. Do I have > this correct? > > thx, > - Kevin > > ----- End forwarded message ----- > At 12:18 PM 2/21/2008, Mark Townsley wrote: > > >Secretary, > > > >Please clarify to the RFC Editor that: > > > >RFC 2890 updates RFC 2784. Neither are an update of RFC 1701 or 1702. > > > >RFC 1702 is not supposed to be an update of 1701, it's supposed to > >be an orthogonal and complementary document. > > > >Thank you, > > > >- Mark > > From wwwrun@core3.amsl.com Wed Feb 27 16:38:32 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m1S0Zbvo028044 for ; Wed, 27 Feb 2008 16:35:37 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 67D8E28C0E7; Wed, 27 Feb 2008 16:35:42 -0800 (PST) From: "Amy Vezza via RT" Reply-To: iesg-secretary@iesg.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #2483 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 27 Feb 2008 16:35:43 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #2483] Resolved: Re: draft-ietf-smime-symkeydist-10.txt Status: O X-Status: X-Keywords: $Junk X-UID: 15 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Wed Feb 27 16:38:37 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m1S0Zb3x028043 for ; Wed, 27 Feb 2008 16:35:37 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 583123A6A1F; Wed, 27 Feb 2008 16:35:42 -0800 (PST) From: "Amy Vezza via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080225212907.GE8375@isi.edu> References: <20080221223001.C680C3A6C66@core3.amsl.com> <20080225212907.GE8375@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #2483 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 27 Feb 2008 16:35:43 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #2483] Re: draft-ietf-smime-symkeydist-10.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 16 Hi Sandy, I believe we have unraveled the two messages from each other, and you should have received two revised messages today with both these issues as the IESG intended alert you to them. Please let us know if there are any other questions regarding either issue. Thank you! Amy On Mon Feb 25 13:42:09 2008, rfc-editor@rfc-editor.org wrote: > Greetings IESG Secretariat, > > It looks like 2 messages got crossed here. > > We have updated our queue to reflect v10 for > draft-ietf-smime-symkeydist-10.txt and we will use v10 as our starting > point for publication. However, the message states "For more > background information, please see the trail below:", but the mail > messages below are about the relationship between RFCs 1701, 2784, and > 2890. > > Could you please resend the messages (i.e., the one with the > appropriate trail information for draft-ietf-smime-symkeydist-10.txt > and the response to the relation between RFCs 1701, 2784, and 2890)? > > Thanks! > > Sandy > > > > On Thu, Feb 21, 2008 at 02:30:01PM -0800, The IESG wrote: > > Subject: draft-ietf-smime-symkeydist-10.txt > > > > This document has been in the RFC Editor queue since February > > 2003. It has been waiting on a normative dependency on > > draft-ietf-pkix-2797-bis. That document is finally close to > > publication -- just two more IESG DISCUSS positions to resolve. Some > > things have changed in the five years that this document has been > > waiting, so the author just posted an update to align the two > > documents. Considering the time that has passed, the changes are > > very few. Please accept this update, and treat these changes similar > > to Auth48 changes. The IESG has reviewed them, and they do not > > require further review. > > > > For more background information, please see the trail below: > > > > Date: Mon, 3 Dec 2007 11:48:35 -0800 > > From: RFC Editor > > To: IESG > > Cc: kfall@cs.berkeley.edu, RFC Editor > > Subject: RFC database: additional information regarding GRE RFC's > > > > IESG, > > > > We received this inquiry below about the relationships between some > > GRE RFCs. Do you have any input on whether RFC 1701 should be > > updated/obsoleted by RFC 2784? > > > > Thanks, > > Sandy > > > > ----- Forwarded message from Kevin Fall ----- > > > > To: rfc-editor@rfc-editor.org > > From: Kevin Fall > > Subject: RFC database: additional information regarding GRE RFC's > > Date: Sat, 17 Nov 2007 15:28:48 -0800 > > > > > > Hi. > > > > I was going through the RFC search tool and noticed that the > > Obsoletes/Updates field for some of the GRE-related RFCs appear to be > > missing. > > > > In particular, I would have expected 1701 to be listed as updated > > (obsoleted?) by 2784, which in turn is updated by 2890. Do I have > > this correct? > > > > thx, > > - Kevin > > > > ----- End forwarded message ----- > > At 12:18 PM 2/21/2008, Mark Townsley wrote: > > > > >Secretary, > > > > > >Please clarify to the RFC Editor that: > > > > > >RFC 2890 updates RFC 2784. Neither are an update of RFC 1701 or 1702. > > > > > >RFC 1702 is not supposed to be an update of 1701, it's supposed to > > >be an orthogonal and complementary document. > > > > > >Thank you, > > > > > >- Mark > > > > From wwwrun@core3.amsl.com Thu Mar 6 11:17:57 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m26JH1EZ027373 for ; Thu, 6 Mar 2008 11:17:01 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id BC8803A6A89; Thu, 6 Mar 2008 11:17:10 -0800 (PST) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080306191449.GA840@isi.edu> References: <469B63A4.7090407@cisco.com> <20080306191449.GA840@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #2944 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 06 Mar 2008 11:17:10 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #2944] AutoReply: Re: Approved under draft-irtf-rfcs-00 experiment: draft-irtf-hiprg-nat-04.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 17 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Approved under draft-irtf-rfcs-00 experiment: draft-irtf-hiprg-nat-04.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #2944]. Please include the string: [rt.amsl.com #2944] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- Hi Mark and IESG Secretariat, We have been getting this document ready for publication (along with the rest of the HIP documents), but I realized that we never received the formal "no objection" message from the IESG Secretariat. The I-D tracker lists the state as "Approved-announcement to be sent". We can move this document to AUTH48, but we do not want to publish the document until we have received the notice from the IESG Secretariat. I don't know who has the token on this, but can one of you arrange for the announcement to be sent? Please let me know if there are any questions or problems. Thanks! Sandy On Mon, Jul 16, 2007 at 02:25:08PM +0200, Mark Townsley wrote: > > Dear Editor, > > draft-irtf-hiprg-nat-03.txt received an "RFC 3932 IESG Review" which did > result in a small update to the document and is reflected in version > -04. The current version is now "approved" (note the quotes) from the > perspective of the IESG. This was done according to the experimental > IRTF document handling process described in draft-irtf-rfcs-00.txt. > According to section 2.6, the IESG is supposed to identify the proper > disclaimer to be inserted in the document. That disclaimer should be: > > "This RFC is a product of the Internet Research Task Force and > is not a candidate for any level of Internet Standard. The > IRTF publishes the results of Internet-related research and > development activities. These results might not be suitable > for deployment." > > According to section 2.5 and 2.7 of draft-irtf-rfcs-00, the next step > now is to hand the document to the RFC Editor for handling as follows: > > 2.5. RFC Editor Handling > > The document is submitted to the RFC Editor who does not perform an > ISR review. The RFC Editor sends it to the IESG for an RFC3932 > review. There are several reasons why the IESG may block a document, > described in RFC3932 section 4. (The document shepherd should be > responsible for checking the IETF datatracker for IESG blocking and > non-blocking comments and forward them to the RG.) > > 2.7. Exiting > > The document enters the RFC Editor queue at the same priority as IETF > documents. The document shepherd is responsible for ensuring that > the document authors are responsive to the RFC Editor and that the > RFC editing process goes smoothly. > > Let me know if there is anything else you are expecting from me or the > IESG. > > Thanks, > > - Mark > > PS. This request was originally sent to the iesg-secretary to be > communicated, in turn, to the RFC Editor. This created some procedural > discussion which has not been fully hashed out and understood by all. > Suffice to say that this document need not be held up any longer > though, and that we will nail down the proper set of procedures > in due course of the completion of draft-irtf-rfcs-xx.txt > > From wwwrun@core3.amsl.com Fri Mar 21 11:54:52 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m2LIr2KS003778 for ; Fri, 21 Mar 2008 11:53:03 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id E644928C32B; Fri, 21 Mar 2008 11:55:19 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080321185147.GB15166@isi.edu> References: <20080321185147.GB15166@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #5844 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 21 Mar 2008 11:55:19 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #5844] AutoReply: Informational Independent Submission: draft-sanjib-private-vlan-09.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 18 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Informational Independent Submission: draft-sanjib-private-vlan-09.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #5844]. Please include the string: [rt.amsl.com #5844] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- IESG, This RFC-to-be was submitted to the RFC Editor to be published as Informational: draft-sanjib-private-vlan-09.txt. Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Four week timeout expires on 18 April 2008. Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment This document describes a mechanism to achieve device isolation through the application of special Layer 2 forwarding constraints. Such mechanism allows end devices to share the same IP subnet while being Layer 2 isolated, which in turn allows network designers to employ larger subnets and so reduce the address management overhead. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents From wwwrun@core3.amsl.com Thu Mar 27 12:49:22 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m2RJlVP0022480 for ; Thu, 27 Mar 2008 12:47:32 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 5F0023A6AED; Thu, 27 Mar 2008 12:49:51 -0700 (PDT) Subject: Re: [rt.amsl.com #2944] AutoReply: Re: Approved under draft-irtf-rfcs-00 experiment: draft-irtf-hiprg-nat-04.txt From: "RFC Editor via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080327194532.GF19870@isi.edu> References: <469B63A4.7090407@cisco.com> <20080306191449.GA840@isi.edu> <20080327194532.GF19870@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #2944 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 27 Mar 2008 12:49:51 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Status: O X-Status: X-Keywords: $NotJunk X-UID: 19 Hi Mark, Just a reminder that we are moving toward the publication of a set of documents that are now in AUTH48. is one of the set. However, we have never received the offical "no problem with publication" message from the secretariat. (Please see emails below for more detail.) Could you please work with the secretariat to have the announcement sent? Or, let me know if there are any problems. Thanks! Sandy On Thu, Mar 06, 2008 at 11:17:10AM -0800, IETF-IESG via RT wrote: > > Greetings, > > This message has been automatically generated in response to the > creation of a trouble ticket regarding: > "Re: Approved under draft-irtf-rfcs-00 experiment: draft-irtf-hiprg-nat-04.txt", > a summary of which appears below. > > There is no need to reply to this message right now. Your ticket has been > assigned an ID of [rt.amsl.com #2944]. > > Please include the string: > > [rt.amsl.com #2944] > > in the subject line of all future correspondence about this issue. To do so, > you may reply to this message. > > Thank you, > iesg-secretary@iesg.org > > ------------------------------------------------------------------------- > Hi Mark and IESG Secretariat, > > We have been getting this document ready for publication (along with > the rest of the HIP documents), but I realized that we never received > the formal "no objection" message from the IESG Secretariat. The I-D > tracker lists the state as "Approved-announcement to be sent". > > We can move this document to AUTH48, but we do not want to publish the > document until we have received the notice from the IESG Secretariat. > > I don't know who has the token on this, but can one of you arrange for > the announcement to be sent? > > Please let me know if there are any questions or problems. > > Thanks! > > Sandy > > > On Mon, Jul 16, 2007 at 02:25:08PM +0200, Mark Townsley wrote: > > > > Dear Editor, > > > > draft-irtf-hiprg-nat-03.txt received an "RFC 3932 IESG Review" which did > > result in a small update to the document and is reflected in version > > -04. The current version is now "approved" (note the quotes) from the > > perspective of the IESG. This was done according to the experimental > > IRTF document handling process described in draft-irtf-rfcs-00.txt. > > According to section 2.6, the IESG is supposed to identify the proper > > disclaimer to be inserted in the document. That disclaimer should be: > > > > "This RFC is a product of the Internet Research Task Force and > > is not a candidate for any level of Internet Standard. The > > IRTF publishes the results of Internet-related research and > > development activities. These results might not be suitable > > for deployment." > > > > According to section 2.5 and 2.7 of draft-irtf-rfcs-00, the next step > > now is to hand the document to the RFC Editor for handling as follows: > > > > 2.5. RFC Editor Handling > > > > The document is submitted to the RFC Editor who does not perform an > > ISR review. The RFC Editor sends it to the IESG for an RFC3932 > > review. There are several reasons why the IESG may block a document, > > described in RFC3932 section 4. (The document shepherd should be > > responsible for checking the IETF datatracker for IESG blocking and > > non-blocking comments and forward them to the RG.) > > > > 2.7. Exiting > > > > The document enters the RFC Editor queue at the same priority as IETF > > documents. The document shepherd is responsible for ensuring that > > the document authors are responsive to the RFC Editor and that the > > RFC editing process goes smoothly. > > > > Let me know if there is anything else you are expecting from me or the > > IESG. > > > > Thanks, > > > > - Mark > > > > PS. This request was originally sent to the iesg-secretary to be > > communicated, in turn, to the RFC Editor. This created some procedural > > discussion which has not been fully hashed out and understood by all. > > Suffice to say that this document need not be held up any longer > > though, and that we will nail down the proper set of procedures > > in due course of the completion of draft-irtf-rfcs-xx.txt > > > > > From wwwrun@core3.amsl.com Mon Apr 7 13:51:39 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m37Kmr2L001454 for ; Mon, 7 Apr 2008 13:48:54 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 3B1E928C3D4; Mon, 7 Apr 2008 13:48:34 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080407204722.GC16867@isi.edu> References: <20080407204722.GC16867@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #6272 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Mon, 07 Apr 2008 13:48:34 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #6272] AutoReply: Informational Independent Submission: draft-guy-iax-04.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 20 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Informational Independent Submission: draft-guy-iax-04.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #6272]. Please include the string: [rt.amsl.com #6272] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- IESG, This RFC-to-be was submitted to the RFC Editor to be published as Informational: draft-guy-iax-04.txt. Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Four week timeout expires on 5 May 2008. IAX: Inter-Asterisk eXchange Version 2 This document describes IAX, the Inter-Asterisk eXchange protocol, an application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks. IAX was developed by the open source community for the Asterisk PBX and is targeted primarily at Voice over Internet Protocol (VoIP) call control, but it can be used with streaming video or any other type of multimedia. IAX is an "all in one" protocol for handling multimedia in IP networks. It combines both control and media services in the same protocol. In addition, IAX uses a single UDP data stream on a static port greatly simplifying Network Address Translation (NAT) gateway traversal, eliminating the need for other protocols to work around NAT, and simplifying network and firewall management. IAX employs a compact encoding which decreases bandwidth usage and is well suited for Internet telephony service. In addition, its open nature permits new payload types additions needed to support additional services. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents From wwwrun@core3.amsl.com Mon Apr 7 13:51:44 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m37KnLZ2001701 for ; Mon, 7 Apr 2008 13:49:22 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id D71E33A6B6C; Mon, 7 Apr 2008 13:49:06 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080407204722.GC16867@isi.edu> References: <20080407204722.GC16867@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #6273 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Mon, 07 Apr 2008 13:49:06 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #6273] AutoReply: Informational Independent Submission: draft-guy-iax-04.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 21 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Informational Independent Submission: draft-guy-iax-04.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #6273]. Please include the string: [rt.amsl.com #6273] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- IESG, This RFC-to-be was submitted to the RFC Editor to be published as Informational: draft-guy-iax-04.txt. Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Four week timeout expires on 5 May 2008. IAX: Inter-Asterisk eXchange Version 2 This document describes IAX, the Inter-Asterisk eXchange protocol, an application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks. IAX was developed by the open source community for the Asterisk PBX and is targeted primarily at Voice over Internet Protocol (VoIP) call control, but it can be used with streaming video or any other type of multimedia. IAX is an "all in one" protocol for handling multimedia in IP networks. It combines both control and media services in the same protocol. In addition, IAX uses a single UDP data stream on a static port greatly simplifying Network Address Translation (NAT) gateway traversal, eliminating the need for other protocols to work around NAT, and simplifying network and firewall management. IAX employs a compact encoding which decreases bandwidth usage and is well suited for Internet telephony service. In addition, its open nature permits new payload types additions needed to support additional services. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents From wwwrun@core3.amsl.com Tue Apr 8 11:56:50 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.4 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m38IsU3O012652 for ; Tue, 8 Apr 2008 11:54:31 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 0454828C17F; Tue, 8 Apr 2008 11:54:13 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080408185151.GC22423@isi.edu> References: <20080321185147.GB15166@isi.edu> <20080408185151.GC22423@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #6312 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 08 Apr 2008 11:54:13 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #6312] AutoReply: Re: Informational Independent Submission: draft-sanjib-private-vlan-09.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 22 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Informational Independent Submission: draft-sanjib-private-vlan-09.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #6312]. Please include the string: [rt.amsl.com #6312] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- Greetings, We are resending this message, as we note that the ID tracker lists this document as being in ID Exists. Thanks! RFC Editor On Fri, Mar 21, 2008 at 11:51:47AM -0700, RFC Editor wrote: > IESG, > > This RFC-to-be was submitted to the RFC Editor to be published as > Informational: draft-sanjib-private-vlan-09.txt. > > Please let us know if this document conflicts with the IETF standards > process or other work being done in the IETF community. > > Four week timeout expires on 18 April 2008. > > Cisco Systems' Private VLANs: > Scalable Security in a Multi-Client Environment > > This document describes a mechanism to achieve device isolation > through the application of special Layer 2 forwarding constraints. > Such mechanism allows end devices to share the same IP subnet while > being Layer 2 isolated, which in turn allows network designers to > employ larger subnets and so reduce the address management > overhead. > > > > Sincerely, > > Sandy Ginoza - USC/ISI > Request for Comments Documents From wwwrun@core3.amsl.com Wed Apr 9 07:43:52 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.4 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m39EgeQu027855 for ; Wed, 9 Apr 2008 07:42:41 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 939A73A6D03; Wed, 9 Apr 2008 07:42:21 -0700 (PDT) From: "Amy Vezza via RT" Reply-To: iesg-secretary@iesg.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #2944 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 09 Apr 2008 07:42:21 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #2944] Resolved: Re: Approved under draft-irtf-rfcs-00 experiment: draft-irtf-hiprg-nat-04.txt Status: O X-Status: X-Keywords: $Junk X-UID: 23 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Wed Apr 16 10:30:10 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m3GHTHQ1005876 for ; Wed, 16 Apr 2008 10:29:18 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id D47A428C4C1; Wed, 16 Apr 2008 10:28:40 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080416172748.GC13818@isi.edu> References: <20070213205056.GM7571@isi.edu> <20080416172748.GC13818@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #6524 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 16 Apr 2008 10:28:40 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #6524] AutoReply: Re: Experimental RFC to be: draft-blanchet-v6ops-tunnelbroker-tsp-03.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 24 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Experimental RFC to be: draft-blanchet-v6ops-tunnelbroker-tsp-03.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #6524]. Please include the string: [rt.amsl.com #6524] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- Greetings All, Just a friendly reminder -- We do not believe we have received a response for this request for an RFC 3932 review. Please let us know the status of this document. Thank you. RFC Editor On Tue, Feb 13, 2007 at 12:50:56PM -0800, RFC Editor wrote: > IESG, > > This RFC-to-be was submitted to the RFC Editor to be published as > Experimental: draft-blanchet-v6ops-tunnelbroker-tsp-03.txt. > > Following Brian's suggestion, this document is being submitted to the > IESG for early RFC 3932 review, since it contains a WG name in its > file name. > > Please let us know if this document conflicts with the IETF standards > process or other work being done in the IETF community. > > Four week timeout expires on 13 March 2007. > > > IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP) > > A tunnel broker with the Tunnel Setup Protocol (TSP) enables the > establishment of tunnels of various inner protocols, such as IPv6 > or IPv4, inside various outer protocols packets, such as IPv4, IPv6 > or UDP over IPv4 for IPv4 NAT traversal. The control protocol > (TSP) is used by the tunnel client to negotiate the tunnel with the > broker. A mobile node implementing TSP can be connected to both > IPv4 and IPv6 networks whether it is on IPv4 only, IPv4 behind a > NAT or on IPv6 only. A tunnel broker may terminate the tunnels on > remote tunnel servers or on itself. This document describes the > TSP protocol within the model of the tunnel broker model. > > > Sincerely, > > Sandy Ginoza - USC/ISI > Request for Comments Documents > From wwwrun@core3.amsl.com Thu Apr 17 09:56:02 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m3HGtFTO019833 for ; Thu, 17 Apr 2008 09:55:16 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 6CD973A6AD7; Thu, 17 Apr 2008 09:54:36 -0700 (PDT) From: "Amy Vezza via RT" Reply-To: iesg-secretary@iesg.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #6537 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org, townsley@cisco.com MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 17 Apr 2008 09:54:36 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #6537] Resolved: Re: Experimental RFC to be: draft-blanchet-v6ops-tunnelbroker-tsp-03.txt Status: O X-Status: X-Keywords: $Junk X-UID: 25 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Tue Apr 29 17:42:37 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.0 required=4.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m3U0fsJN028011 for ; Tue, 29 Apr 2008 17:41:55 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id C306128C323; Tue, 29 Apr 2008 17:41:48 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080430004014.GC23710@isi.edu> References: <20080429145957.7C20A3A6CFA@core3.amsl.com> <20080430004014.GC23710@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #6891 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 29 Apr 2008 17:41:48 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #6891] AutoReply: Re: Protocol Action: 'Sieve Email Filtering: Environment Extension' to Proposed Standard Status: O X-Status: X-Keywords: $NotJunk X-UID: 26 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Sieve Email Filtering: Environment Extension' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #6891]. Please include the string: [rt.amsl.com #6891] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Tue, Apr 29, 2008 at 07:59:57AM -0700, The IESG wrote: > The IESG has approved the following document: > > - 'Sieve Email Filtering: Environment Extension ' > as a Proposed Standard > > This document has been reviewed in the IETF but is not the product of an > IETF Working Group. > > The IESG contact person is Chris Newman. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-freed-sieve-environment-05.txt > > Technical Summary > > This document describes the "environment" extension to the Sieve > email filtering language. The "environment" extension gives a > Sieve script access to information about the Sieve interpreter > itself, where it is running, and about any transport connection > currently involved in transferring the message. > > > Working Group Summary > > This is an individual submission, but the document was extensively > reviewed on the Sieve WG mailing list. There was strong support > in favor of this document from implementors. There were some > discussions about list of initial attributes specified in the > document, but most of them were centered around naming. > > IETF Last Call Summary > > There was fairly extensive discussion during IETF last call > which resulted in several improvements to the document. It was > noted during last call that the extension has two different kinds > of environment information: static information about the evaluation > engine and dynamic information about remote IP/host. The community > felt it was not a problem to have one syntax cover both kinds of > environment data. > > Document Quality > > At least 5 people have reviewed the current or earlier versions > of the document. Posted comments were addressed in the latest > revision. There is 1 existing implementation and at least 3 > more are planned. > > Personnel > > Alexey Melnikov is the document shepherd. Chris Newman is the > responsible area director. > > Note to RFC Editor > > Abstract > OLD: > The "environment" extension gives Sieve access to information > about the environment where the Sieve interpreter is running. > NEW: > The "environment" extension gives a Sieve script access to > information about the Sieve interpreter itself, where it is > running, and about any transport connection currently involved > in transferring the message. From wwwrun@core3.amsl.com Tue Apr 29 18:04:33 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m3U13uMG006609 for ; Tue, 29 Apr 2008 18:03:57 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id AC0823A6BFF; Tue, 29 Apr 2008 18:03:51 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080430010249.GD23710@isi.edu> References: <20080430010249.GD23710@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #6892 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 29 Apr 2008 18:03:52 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #6892] AutoReply: Experimental IRTF Submission: draft-irtf-dtnrg-ltp-09.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 27 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Experimental IRTF Submission: draft-irtf-dtnrg-ltp-09.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #6892]. Please include the string: [rt.amsl.com #6892] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- IESG, This RFC-to-be was submitted to the RFC Editor to be published as Experimental: draft-irtf-dtnrg-ltp-09.txt. This document is a product of the IRTF. The review history for this document can be found at: http://www3.tools.ietf.org/group/irtf/trac/ticket/21 Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Four week timeout expires on 27 May 2008. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents ----- Forwarded message from Aaron Falk ----- Cc: Internet Research Steering Group , Kevin Fall From: Aaron Falk To: RFC Editor Subject: Request to publish 3 IRTF drafts: draft-irtf-dtnrg-{ltp, ltp-extensions, ltp-motivation} Date: Mon, 28 Apr 2008 19:47:59 -0700 Dear RFC Editor- Please publish the drafts: draft-irtf-dtnrg-ltp-09.txt draft-irtf-dtnrg-ltp-extensions-07.txt draft-irtf-dtnrg-ltp-motivation-06.txt as IRTF RFCs. The note below explains the review the drafts have undergone and the desired category to which they should be published. Kevin Fall (cc'ed) is to be the document shepherd for these drafts. Please be sure to copy him on communications with the authors. I believe it is desired that the documents be published together. Regards, --aaron falk IRTF Chair Begin forwarded message: >From: Kevin Fall >Date: April 28, 2008 7:34:05 PM PDT >To: Aaron Falk >Cc: Internet Research Steering Group , Delay Tolerant >Networking Interest List >Subject: Advancing the LTP documents > >Hi Aaron, IRSG, and DTNRG-- > >In accordance with current IRTF RFC processes, three of the >LTP-related documents [1-3] have now finished IRSG review >and are ready for you to send to the RFC editor. Documents [1-2] >are intended as Experimental RFCs, and document [3] is intended >as an Informational RFC. > >The respective tracker tickets [4-6] for these docs have links >to the various stages of the review. In particular, the >"Attachments" section in each ticket contains text files with >pointers to and/or specific review comments that came up >during either RG or IRSG review. > >Brief of discussion items by doc: > >[base]: > - concern about non-congestion-controlled LTP protocol > running atop UDP could be bad for the Internet. Document > now specifies LTP is designed for private links > > - LTP does not provide flow control. The consequence > of using lower-layer "link queues" is discussed in the > spec > > - LTP has "red" and "green" color segments that refer > to whether reliability is provided or not. There was > some confusion as to whether network-induced re-ordering > between red/green segments was a problem. [its not] > >[extensions]: > > - the extensions are really only security-related, so > the title now reflects this fact > >[motivation]: > > - some concern about the number of timers required, clarified > by a message on 2/7/07 as not being so huge > >I'll be shepherd for these documents. > >Regards, >Kevin. > >[1] http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-ltp-09.txt >[2] >http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-ltp-extensions-07.txt >[3] >http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-ltp-motivation-06.txt > >[4] http://www3.tools.ietf.org/group/irtf/trac/ticket/21 >[5] http://www3.tools.ietf.org/group/irtf/trac/ticket/22 >[6] http://www3.tools.ietf.org/group/irtf/trac/ticket/23 > ----- End forwarded message ----- From wwwrun@core3.amsl.com Tue Apr 29 18:08:03 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m3U17AqV007719 for ; Tue, 29 Apr 2008 18:07:11 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 457ED3A6BAD; Tue, 29 Apr 2008 18:07:07 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080430010531.GE23710@isi.edu> References: <20080430010531.GE23710@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #6893 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 29 Apr 2008 18:07:07 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #6893] AutoReply: Experimental IRTF Submission: draft-irtf-dtnrg-ltp-extensions-07.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 28 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Experimental IRTF Submission: draft-irtf-dtnrg-ltp-extensions-07.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #6893]. Please include the string: [rt.amsl.com #6893] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- IESG, This RFC-to-be was submitted to the RFC Editor to be published as Experimental: draft-irtf-dtnrg-ltp-extensions-07.txt. This document is a product of the IRTF. The reviews for this document can be found at: http://www3.tools.ietf.org/group/irtf/trac/ticket/22 Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Four week timeout expires on 27 May 2008. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents ----- Forwarded message from Aaron Falk ----- Cc: Internet Research Steering Group , Kevin Fall From: Aaron Falk To: RFC Editor Subject: Request to publish 3 IRTF drafts: draft-irtf-dtnrg-{ltp, ltp-extensions, ltp-motivation} Date: Mon, 28 Apr 2008 19:47:59 -0700 Dear RFC Editor- Please publish the drafts: draft-irtf-dtnrg-ltp-09.txt draft-irtf-dtnrg-ltp-extensions-07.txt draft-irtf-dtnrg-ltp-motivation-06.txt as IRTF RFCs. The note below explains the review the drafts have undergone and the desired category to which they should be published. Kevin Fall (cc'ed) is to be the document shepherd for these drafts. Please be sure to copy him on communications with the authors. I believe it is desired that the documents be published together. Regards, --aaron falk IRTF Chair Begin forwarded message: >From: Kevin Fall >Date: April 28, 2008 7:34:05 PM PDT >To: Aaron Falk >Cc: Internet Research Steering Group , Delay Tolerant >Networking Interest List >Subject: Advancing the LTP documents > >Hi Aaron, IRSG, and DTNRG-- > >In accordance with current IRTF RFC processes, three of the >LTP-related documents [1-3] have now finished IRSG review >and are ready for you to send to the RFC editor. Documents [1-2] >are intended as Experimental RFCs, and document [3] is intended >as an Informational RFC. > >The respective tracker tickets [4-6] for these docs have links >to the various stages of the review. In particular, the >"Attachments" section in each ticket contains text files with >pointers to and/or specific review comments that came up >during either RG or IRSG review. > >Brief of discussion items by doc: > >[base]: > - concern about non-congestion-controlled LTP protocol > running atop UDP could be bad for the Internet. Document > now specifies LTP is designed for private links > > - LTP does not provide flow control. The consequence > of using lower-layer "link queues" is discussed in the > spec > > - LTP has "red" and "green" color segments that refer > to whether reliability is provided or not. There was > some confusion as to whether network-induced re-ordering > between red/green segments was a problem. [its not] > >[extensions]: > > - the extensions are really only security-related, so > the title now reflects this fact > >[motivation]: > > - some concern about the number of timers required, clarified > by a message on 2/7/07 as not being so huge > >I'll be shepherd for these documents. > >Regards, >Kevin. > >[1] http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-ltp-09.txt >[2] >http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-ltp-extensions-07.txt >[3] >http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-ltp-motivation-06.txt > >[4] http://www3.tools.ietf.org/group/irtf/trac/ticket/21 >[5] http://www3.tools.ietf.org/group/irtf/trac/ticket/22 >[6] http://www3.tools.ietf.org/group/irtf/trac/ticket/23 > ----- End forwarded message ----- From wwwrun@core3.amsl.com Tue Apr 29 18:09:32 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m3U18pOZ008649 for ; Tue, 29 Apr 2008 18:08:52 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 07BC03A6AFD; Tue, 29 Apr 2008 18:08:47 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080430010747.GF23710@isi.edu> References: <20080430010747.GF23710@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #6894 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 29 Apr 2008 18:08:48 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #6894] AutoReply: Informational IRTF Submission: draft-irtf-dtnrg-ltp-motivation-06.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 29 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Informational IRTF Submission: draft-irtf-dtnrg-ltp-motivation-06.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #6894]. Please include the string: [rt.amsl.com #6894] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- IESG, This RFC-to-be was submitted to the RFC Editor to be published as Informational: draft-irtf-dtnrg-ltp-motivation-06.txt. This document is a product of the IRTF. The reviews for this document can be found at: http://www3.tools.ietf.org/group/irtf/trac/ticket/23 Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Four week timeout expires on 27 May 2008. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents ----- Forwarded message from Aaron Falk ----- Cc: Internet Research Steering Group , Kevin Fall From: Aaron Falk To: RFC Editor Subject: Request to publish 3 IRTF drafts: draft-irtf-dtnrg-{ltp, ltp-extensions, ltp-motivation} Date: Mon, 28 Apr 2008 19:47:59 -0700 Dear RFC Editor- Please publish the drafts: draft-irtf-dtnrg-ltp-09.txt draft-irtf-dtnrg-ltp-extensions-07.txt draft-irtf-dtnrg-ltp-motivation-06.txt as IRTF RFCs. The note below explains the review the drafts have undergone and the desired category to which they should be published. Kevin Fall (cc'ed) is to be the document shepherd for these drafts. Please be sure to copy him on communications with the authors. I believe it is desired that the documents be published together. Regards, --aaron falk IRTF Chair Begin forwarded message: >From: Kevin Fall >Date: April 28, 2008 7:34:05 PM PDT >To: Aaron Falk >Cc: Internet Research Steering Group , Delay Tolerant >Networking Interest List >Subject: Advancing the LTP documents > >Hi Aaron, IRSG, and DTNRG-- > >In accordance with current IRTF RFC processes, three of the >LTP-related documents [1-3] have now finished IRSG review >and are ready for you to send to the RFC editor. Documents [1-2] >are intended as Experimental RFCs, and document [3] is intended >as an Informational RFC. > >The respective tracker tickets [4-6] for these docs have links >to the various stages of the review. In particular, the >"Attachments" section in each ticket contains text files with >pointers to and/or specific review comments that came up >during either RG or IRSG review. > >Brief of discussion items by doc: > >[base]: > - concern about non-congestion-controlled LTP protocol > running atop UDP could be bad for the Internet. Document > now specifies LTP is designed for private links > > - LTP does not provide flow control. The consequence > of using lower-layer "link queues" is discussed in the > spec > > - LTP has "red" and "green" color segments that refer > to whether reliability is provided or not. There was > some confusion as to whether network-induced re-ordering > between red/green segments was a problem. [its not] > >[extensions]: > > - the extensions are really only security-related, so > the title now reflects this fact > >[motivation]: > > - some concern about the number of timers required, clarified > by a message on 2/7/07 as not being so huge > >I'll be shepherd for these documents. > >Regards, >Kevin. > >[1] http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-ltp-09.txt >[2] >http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-ltp-extensions-07.txt >[3] >http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-ltp-motivation-06.txt > >[4] http://www3.tools.ietf.org/group/irtf/trac/ticket/21 >[5] http://www3.tools.ietf.org/group/irtf/trac/ticket/22 >[6] http://www3.tools.ietf.org/group/irtf/trac/ticket/23 > ----- End forwarded message ----- From wwwrun@core3.amsl.com Wed Apr 30 07:03:28 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.0 required=4.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m3UE2jjM023427 for ; Wed, 30 Apr 2008 07:02:46 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 21F083A6E98; Wed, 30 Apr 2008 07:01:57 -0700 (PDT) From: "Amy Vezza via RT" Reply-To: iesg-secretary@iesg.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #6891 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 30 Apr 2008 07:01:58 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #6891] Resolved: Re: Protocol Action: 'Sieve Email Filtering: Environment Extension' to Proposed Standard Status: O X-Status: X-Keywords: $Junk X-UID: 30 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Wed Apr 30 11:43:08 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m3UIfb56008978 for ; Wed, 30 Apr 2008 11:41:38 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id F1E723A6BA4; Wed, 30 Apr 2008 11:41:18 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@iesg.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #6893 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 30 Apr 2008 11:41:18 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #6893] Resolved: Experimental IRTF Submission: draft-irtf-dtnrg-ltp-extensions-07.txt Status: O X-Status: X-Keywords: $Junk X-UID: 31 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Wed Apr 30 11:45:22 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m3UIgrBD009572 for ; Wed, 30 Apr 2008 11:42:53 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id D10F83A6BA4; Wed, 30 Apr 2008 11:42:49 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@iesg.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #6894 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 30 Apr 2008 11:42:49 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #6894] Resolved: Informational IRTF Submission: draft-irtf-dtnrg-ltp-motivation-06.txt Status: O X-Status: X-Keywords: $Junk X-UID: 32 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Wed Apr 30 11:45:52 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m3UIhPW1010153 for ; Wed, 30 Apr 2008 11:43:26 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 8B3F13A69C9; Wed, 30 Apr 2008 11:43:22 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@iesg.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #6892 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 30 Apr 2008 11:43:22 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #6892] Resolved: Experimental IRTF Submission: draft-irtf-dtnrg-ltp-09.txt Status: O X-Status: X-Keywords: $Junk X-UID: 33 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Fri May 2 12:35:17 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m42JX04c025842 for ; Fri, 2 May 2008 12:33:01 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 629AB28C24E; Fri, 2 May 2008 12:32:58 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080502193128.GB26096@isi.edu> References: <20080502193128.GB26096@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #6988 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 02 May 2008 12:32:58 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #6988] AutoReply: Informational Independent Submission: draft-santoni-timestampeddata-03.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 34 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Informational Independent Submission: draft-santoni-timestampeddata-03.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #6988]. Please include the string: [rt.amsl.com #6988] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- IESG, This RFC-to-be was submitted to the RFC Editor to be published as Informational: draft-santoni-timestampeddata-03.txt. Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Syntax for binding documents with time stamps This document describes a syntax which can be used to bind a generic document (or any set of data, not necessarily protected by means of cryptographic techniques) to one or more time-stamp tokens obtained for that document, where "time-stamp token" has the meaning defined in RFC 3161. Additional types of temporal evidence are also supported. This document proposes a simple syntax based on the Cryptographic Message Syntax (RFC 3852). Four week timeout expires on 30 May 2008. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents From wwwrun@core3.amsl.com Fri May 2 15:26:37 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m42MPvmT001513 for ; Fri, 2 May 2008 15:25:58 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 01F383A69A2; Fri, 2 May 2008 15:25:54 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@iesg.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #6988 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 02 May 2008 15:25:54 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #6988] Resolved: Informational Independent Submission: draft-santoni-timestampeddata-03.txt Status: O X-Status: X-Keywords: $Junk X-UID: 35 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Tue May 6 15:28:25 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m46MRVVT011247 for ; Tue, 6 May 2008 15:27:32 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id C601728C4B9; Tue, 6 May 2008 15:27:32 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080506222639.GF2488@isi.edu> References: <20080506222639.GF2488@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #7210 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 06 May 2008 15:27:32 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #7210] AutoReply: draft-templin-autoconf-dhcp-14.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 36 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "draft-templin-autoconf-dhcp-14.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #7210]. Please include the string: [rt.amsl.com #7210] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- Greetings, has been submitted to the RFC Editor for consideration for publication as an RFC. Please do not expire this draft. Thank you. RFC Editor From wwwrun@core3.amsl.com Tue May 6 15:46:16 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m46MjZpQ018917 for ; Tue, 6 May 2008 15:45:36 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 419953A689A; Tue, 6 May 2008 15:45:36 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@iesg.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #7210 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 06 May 2008 15:45:37 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #7210] Resolved: draft-templin-autoconf-dhcp-14.txt Status: O X-Status: X-Keywords: $Junk X-UID: 37 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Wed May 14 12:09:19 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m4EJ7Fe9003486 for ; Wed, 14 May 2008 12:07:16 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id CAE813A6842; Wed, 14 May 2008 12:07:12 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080514190028.GE24579@isi.edu> References: <20080502193128.GB26096@isi.edu> <20080514190028.GE24579@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #7337 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 14 May 2008 12:07:12 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #7337] AutoReply: Re: Informational Independent Submission: draft-santoni-timestampeddata-03.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 38 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Informational Independent Submission: draft-santoni-timestampeddata-03.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #7337]. Please include the string: [rt.amsl.com #7337] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- IESG, Please note that a problem has arisen with the OID registration for this draft, and until it is settled satisfactorily by the author, we wish to withdraw the draft from TO. We apologize for any confusion or inconvenience! Thanks, Sandy On Fri, May 02, 2008 at 12:31:28PM -0700, RFC Editor wrote: > IESG, > > This RFC-to-be was submitted to the RFC Editor to be published as > Informational: draft-santoni-timestampeddata-03.txt. > > Please let us know if this document conflicts with the IETF standards > process or other work being done in the IETF community. > > > Syntax for binding documents with time stamps > > This document describes a syntax which can be used to bind a generic > document (or any set of data, not necessarily protected by means of > cryptographic techniques) to one or more time-stamp tokens obtained > for that document, where "time-stamp token" has the meaning defined > in RFC 3161. Additional types of temporal evidence are also > supported. > > This document proposes a simple syntax based on the Cryptographic > Message Syntax (RFC 3852). > > > Four week timeout expires on 30 May 2008. > > > Sincerely, > > Sandy Ginoza - USC/ISI > Request for Comments Documents From wwwrun@core3.amsl.com Tue May 20 20:42:08 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m4L3eV0A010384 for ; Tue, 20 May 2008 20:40:32 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 95FBE3A6CA9; Tue, 20 May 2008 20:40:15 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080520163922.GB3818@isi.edu> References: <20080520163922.GB3818@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #7431 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 20 May 2008 20:40:15 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #7431] AutoReply: draft-bambenek-doubleflux-00.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 39 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "draft-bambenek-doubleflux-00.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #7431]. Please include the string: [rt.amsl.com #7431] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- Greetings, has been submitted to the RFC Editor for consideration for publication as an RFC. Please do not expire this draft. Thank you. RFC Editor From wwwrun@core3.amsl.com Wed May 21 09:08:55 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m4LG7C5K013581 for ; Wed, 21 May 2008 09:07:13 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id EC4503A6979; Wed, 21 May 2008 09:07:07 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@iesg.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #7431 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 21 May 2008 09:07:07 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #7431] Resolved: draft-bambenek-doubleflux-00.txt Status: O X-Status: X-Keywords: $Junk X-UID: 40 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Wed May 21 09:18:50 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m4LGEjvW017274 for ; Wed, 21 May 2008 09:14:45 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 08D7C28C1FF; Wed, 21 May 2008 09:14:39 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080521161354.GB20980@isi.edu> References: <20080521161354.GB20980@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #7457 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 21 May 2008 09:14:40 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #7457] AutoReply: Informational Independent Submission: draft-jcurran-v6transitionplan-03.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 41 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Informational Independent Submission: draft-jcurran-v6transitionplan-03.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #7457]. Please include the string: [rt.amsl.com #7457] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- IESG, This RFC-to-be was submitted to the RFC Editor to be published as Informational: draft-jcurran-v6transitionplan-03.txt. Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Four week timeout expires on 18 June 2008. An Internet Transition Plan This memo provides one possible plan for transitioning the Internet from a predominantly IPv4-based connectivity model to a predominantly IPv6-based connectivity model. This document was reviewed by Bob Hinden. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents From wwwrun@core3.amsl.com Wed May 21 09:24:35 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m4LGMMHC021215 for ; Wed, 21 May 2008 09:22:23 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 36FBA28C106; Wed, 21 May 2008 09:22:18 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080521162035.GC20980@isi.edu> References: <20080521162035.GC20980@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #7459 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 21 May 2008 09:22:18 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #7459] AutoReply: Informational Independent Submission: draft-floyd-tsvwg-besteffort-04.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 42 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Informational Independent Submission: draft-floyd-tsvwg-besteffort-04.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #7459]. Please include the string: [rt.amsl.com #7459] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- IESG, This RFC-to-be was submitted to the RFC Editor to be published as Informational: draft-floyd-tsvwg-besteffort-04.txt. Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Four week timeout expires on 18 June 2008. Comments on the Usefulness of Simple Best-Effort Traffic This document presents some observations on "simple best-effort" traffic, defined loosely for the purposes of this document as Internet traffic that is not covered by Quality of Service mechanisms, congestion-based pricing, cost-based fairness, admissions control, or the like. One observation is that simple best-effort traffic serves a useful role in the Internet, and is worth keeping. While differential treatment of traffic can clearly be useful, we believe such mechanisms are useful as **adjuncts** to simple best-effort traffic, not as **replacements** of simple best-effort traffic. A second observation is that for simple best-effort traffic, some form of rough flow rate fairness is a useful goal for resource allocation, where "flow rate fairness" is defined by the goal of equal flow rates for different flows over the same path. This document was reviewed by Ted Faber. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents From wwwrun@core3.amsl.com Wed May 21 10:04:15 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m4LH2qqV009519 for ; Wed, 21 May 2008 10:02:53 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 2FC323A6ACB; Wed, 21 May 2008 10:02:47 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@iesg.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #7457 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 21 May 2008 10:02:47 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #7457] Resolved: Informational Independent Submission: draft-jcurran-v6transitionplan-03.txt Status: O X-Status: X-Keywords: $Junk X-UID: 43 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Thu May 22 09:17:53 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m4MGHA8o015062 for ; Thu, 22 May 2008 09:17:11 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id E77CA3A6B02; Thu, 22 May 2008 09:17:09 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080522161631.GD13668@isi.edu> References: <20080522161631.GD13668@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #7488 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 22 May 2008 09:17:09 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #7488] AutoReply: draft-saleem-msml-06.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 44 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "draft-saleem-msml-06.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #7488]. Please include the string: [rt.amsl.com #7488] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- Greetings, We believe that has mistakenly been allowed to expire. This document is under consideration for pubication with the RFC Editor. Please revive version -06 in the internet-drafts repository. Please let us know if this poses any problems or if you have any questions. Thank you. RFC Editor From wwwrun@core3.amsl.com Fri May 23 13:23:58 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m4NKMdVK013080 for ; Fri, 23 May 2008 13:22:40 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id ABFF228C306; Fri, 23 May 2008 13:22:39 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@iesg.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #7459 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 23 May 2008 13:22:39 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #7459] Resolved: Informational Independent Submission: draft-floyd-tsvwg-besteffort-04.txt Status: O X-Status: X-Keywords: $Junk X-UID: 45 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Thu May 29 12:25:00 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m4TJ1GKS016395 for ; Thu, 29 May 2008 12:01:16 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id EB6E53A6B87; Thu, 29 May 2008 12:00:41 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@iesg.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #7488 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 29 May 2008 12:00:41 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #7488] Resolved: draft-saleem-msml-06.txt Status: O X-Status: X-Keywords: $Junk X-UID: 46 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Thu May 29 12:25:02 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m4TJ0vt0016084 for ; Thu, 29 May 2008 12:00:58 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 5F47D28C295; Thu, 29 May 2008 12:00:28 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080522161631.GD13668@isi.edu> References: <20080522161631.GD13668@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #7488 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 29 May 2008 12:00:28 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #7488] draft-saleem-msml-06.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 47 Dear RFC Editor, draft-saleem-msml's status is still in Active (not Expired) in the database; however, the draft's state in the I-D tracker is Dead because the IESG sent out a DNP notice on this draft. (In this case, "Status" and "State" refer to two different things.) The draft was marked as "Under Review by RFC Editor" in the database, so it should not expire in August 2008 as it was originally expected to. The draft itself is still active and accessible from the Internet Draft Database Interface at https://datatracker.ietf.org/drafts/draft-saleem-msml/ Best regards, Cindy On Thu May 22 09:17:09 2008, rfc-editor@rfc-editor.org wrote: > Greetings, > > We believe that has mistakenly been allowed > to expire. This document is under consideration for pubication with > the RFC Editor. Please revive version -06 in the internet-drafts > repository. > > Please let us know if this poses any problems or if you have any > questions. > > Thank you. > > RFC Editor > From wwwrun@core3.amsl.com Thu May 29 15:20:48 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m4TMEX30001887 for ; Thu, 29 May 2008 15:14:34 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 917573A6BB6; Thu, 29 May 2008 15:14:33 -0700 (PDT) Subject: Re: [rt.amsl.com #7488] draft-saleem-msml-06.txt From: "RFC Editor via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080529220955.GF28433@isi.edu> References: <20080522161631.GD13668@isi.edu> <20080529220955.GF28433@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #7488 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 29 May 2008 15:14:33 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Status: O X-Status: X-Keywords: $NotJunk X-UID: 48 Thanks for the clarification! Sandy On Thu, May 29, 2008 at 12:00:28PM -0700, Cindy Morgan via RT wrote: > Dear RFC Editor, > > draft-saleem-msml's status is still in Active (not Expired) in the > database; however, the draft's state in the I-D tracker is Dead because > the IESG sent out a DNP notice on this draft. (In this case, "Status" > and "State" refer to two different things.) > > The draft was marked as "Under Review by RFC Editor" in the database, so > it should not expire in August 2008 as it was originally expected to. > The draft itself is still active and accessible from the Internet Draft > Database Interface at https://datatracker.ietf.org/drafts/draft-saleem-msml/ > > Best regards, > Cindy > > > On Thu May 22 09:17:09 2008, rfc-editor@rfc-editor.org wrote: > > Greetings, > > > > We believe that has mistakenly been allowed > > to expire. This document is under consideration for pubication with > > the RFC Editor. Please revive version -06 in the internet-drafts > > repository. > > > > Please let us know if this poses any problems or if you have any > > questions. > > > > Thank you. > > > > RFC Editor > > > > From wwwrun@core3.amsl.com Thu May 29 16:27:54 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m4TNOif5009899 for ; Thu, 29 May 2008 16:24:45 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 9643A3A6B5D; Thu, 29 May 2008 16:24:44 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@iesg.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #7488 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 29 May 2008 16:24:44 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #7488] Resolved: draft-saleem-msml-06.txt Status: O X-Status: X-Keywords: $Junk X-UID: 49 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Mon Jun 2 16:11:13 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m52NA9Fg008570 for ; Mon, 2 Jun 2008 16:10:13 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 1EECA28C17D; Mon, 2 Jun 2008 16:09:33 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080602230530.GE4939@isi.edu> References: <20080602230530.GE4939@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #7750 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Mon, 02 Jun 2008 16:09:34 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #7750] AutoReply: Informational Independent Submission: draft-ietf-ediint-compression-11.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 50 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Informational Independent Submission: draft-ietf-ediint-compression-11.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #7750]. Please include the string: [rt.amsl.com #7750] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- IESG, This RFC-to-be was submitted to the RFC Editor to be published as Informational: draft-ietf-ediint-compression-11.txt. Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Four week timeout expires on 30 June 2008. Compressed Data within an Internet EDI Message This document explains the rules and procedures for utilizing compression (RFC 3274) within an Internet EDI (Electronic Data Interchange) 'AS' message, as defined in RFCs 3335, 4130, and 4823. This document was reviewed by the RFC Editor and by Jim Schaad, with additional input from Harald Alvestrand, and the document was updated to meet all reviewer recommendations. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents From wwwrun@core3.amsl.com Wed Jun 4 11:39:27 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m54Iccfh018875 for ; Wed, 4 Jun 2008 11:38:39 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 95E7A28C1F5; Wed, 4 Jun 2008 11:38:33 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@iesg.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #7750 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 04 Jun 2008 11:38:33 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #7750] Resolved: Informational Independent Submission: draft-ietf-ediint-compression-11.txt Status: O X-Status: X-Keywords: $Junk X-UID: 51 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Thu Jun 5 15:48:20 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m55MkWHX016617 for ; Thu, 5 Jun 2008 15:46:33 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id EB0733A6815; Thu, 5 Jun 2008 15:46:24 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080605224443.GE23686@isi.edu> References: <20080605224443.GE23686@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #7813 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 05 Jun 2008 15:46:24 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #7813] AutoReply: Informational Independent Submission: draft-munakata-sip-privacy-guideline-03.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 52 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Informational Independent Submission: draft-munakata-sip-privacy-guideline-03.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #7813]. Please include the string: [rt.amsl.com #7813] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- IESG, This RFC-to-be was submitted to the RFC Editor to be published as Informational: draft-munakata-sip-privacy-guideline-03.txt. Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Four week timeout expires on 3 July 2008. Guidelines for Using the Privacy Mechanism for SIP This is an informational document that provides guidelines for using the privacy mechanism for Session Initiation Protocol (SIP), that is specified in RFC 3323 and subsequently extended in RFCs 3325 and 4244. It is intended to clarify the handling of the target SIP headers/parameters and SDP parameters for each of the privacy header values (priv-values). This document was reviewed by Mary Barnes and by Joel Halpern. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents From wwwrun@core3.amsl.com Fri Jun 6 10:18:29 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m56HI2xw008921 for ; Fri, 6 Jun 2008 10:18:03 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 0C3CD3A6914; Fri, 6 Jun 2008 10:17:51 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@iesg.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #7813 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 06 Jun 2008 10:17:52 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #7813] Resolved: Informational Independent Submission: draft-munakata-sip-privacy-guideline-03.txt Status: O X-Status: X-Keywords: $Junk X-UID: 53 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Tue Jun 10 19:11:29 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.1 required=4.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m5B29jBP016288 for ; Tue, 10 Jun 2008 19:09:46 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 045753A6853; Tue, 10 Jun 2008 19:09:20 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080611020915.GE21895@isi.edu> References: <20080610130852.448FD3A6B66@core3.amsl.com> <20080611020915.GE21895@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #7931 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 10 Jun 2008 19:09:20 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #7931] AutoReply: Re: Protocol Action: 'Session Initiation Protocol (SIP) extension for Partial Notification of Presence Information' to Proposed Standard Status: O X-Status: X-Keywords: $NotJunk X-UID: 54 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Session Initiation Protocol (SIP) extension for Partial Notification of Presence Information' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #7931]. Please include the string: [rt.amsl.com #7931] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Tue, Jun 10, 2008 at 06:08:52AM -0700, The IESG wrote: > The IESG has approved the following documents: > > - 'An Extensible Markup Language (XML) Patch Operations Framework > Utilizing XML Path Language (XPath) Selectors ' > as a Proposed Standard > - 'Presence Information Data format (PIDF) Extension for Partial > Presence ' > as a Proposed Standard > - 'Session Initiation Protocol (SIP) extension for Partial Notification > of Presence Information ' > as a Proposed Standard > - 'Publication of Partial Presence Information ' > as a Proposed Standard > > These documents are products of the SIP for Instant Messaging and > Presence Leveraging Extensions Working Group. > > The IESG contact persons are Jon Peterson and Cullen Jennings. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-notify-10.txt > > Technical Summary > > This document set provides a new capability for SIMPLE: partial > publications and notifications. Partial publications and notifications are > updates to previous transmitted presence documents which omit redundant > information, thereby saving bandwidth and processing. Both of these rely > on a common partial presence document format, 'application/pidf-diff+xml'. > These diffs are applied to existing presence documents through the > patching technique described in the xml-patch-ops document. > > Working Group Summary > > The working group supports the advancement of these specifications, and in > fact much protocol work inside and outside the IETF relies on this. > > Protocol Quality > > These documents were reviewed for the IESG by Jon Peterson. The PROTO > shepherd is Robert Sparks. Apps Area review of the XML-patch-ops document > was provided by Dave Crocker. Gen-ART review of XMLpatch-ops was provided > by Joel Halpern. From wwwrun@core3.amsl.com Tue Jun 10 19:20:53 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.1 required=4.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m5B2JelU019481 for ; Tue, 10 Jun 2008 19:19:40 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id B187F3A68E6; Tue, 10 Jun 2008 19:19:15 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080611020940.GG21895@isi.edu> References: <20080610142506.118913A6937@core3.amsl.com> <20080611020940.GG21895@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #7932 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 10 Jun 2008 19:19:15 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #7932] AutoReply: Re: Document Action: 'Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)' to Informational RFC Status: O X-Status: X-Keywords: $NotJunk X-UID: 55 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #7932]. Please include the string: [rt.amsl.com #7932] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Tue, Jun 10, 2008 at 07:25:05AM -0700, The IESG wrote: > The IESG has approved the following document: > > - 'Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge > (PWE3) ' > as an Informational RFC > > This document is the product of the Pseudowire Emulation Edge to Edge > Working Group. > > The IESG contact persons are Mark Townsley and Jari Arkko. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-ms-pw-requirements-07.txt > > Technical Summary > > This document describes a protocol that provides a control channel > that is associated with a Pseudowire (PW), and its use for > operations and management functions such as connectivity > verification to be used over that control channel. VCCV > applies to all supported access circuit and transport types > currently defined for PWs. > > Working Group Summary > > This document has been reviewed by the experts in the PWE3 WG > and there are no outstanding issues. > > Document Quality > > The document was reviewed by Mark Townsley. Stewart Bryant is the > document shepherd. From wwwrun@core3.amsl.com Tue Jun 10 19:20:58 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.1 required=4.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m5B2Jekj019482 for ; Tue, 10 Jun 2008 19:19:40 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id B803D3A68DD; Tue, 10 Jun 2008 19:19:15 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080611020928.GF21895@isi.edu> References: <20080610131059.81A423A6AC0@core3.amsl.com> <20080611020928.GF21895@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #7933 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 10 Jun 2008 19:19:15 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #7933] AutoReply: Re: Protocol Action: 'LoST: A Location-to-Service Translation Protocol' to Proposed Standard Status: O X-Status: X-Keywords: $NotJunk X-UID: 56 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'LoST: A Location-to-Service Translation Protocol' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #7933]. Please include the string: [rt.amsl.com #7933] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Tue, Jun 10, 2008 at 06:10:59AM -0700, The IESG wrote: > The IESG has approved the following document: > > - 'LoST: A Location-to-Service Translation Protocol ' > as a Proposed Standard > > This document is the product of the Emergency Context Resolution with > Internet Technologies Working Group. > > The IESG contact persons are Jon Peterson and Cullen Jennings. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-10.txt > > Technical Summary > > This document describes an XML-based protocol for mapping service > identifiers and geodetic or civic location information to service > contact URIs. In particular, it can be used to determine the > location-appropriate PSAP for emergency services. > > Working Group Summary > > There is consensus in the WG to publish this document. > > Protocol Quality > > The LoST protocol has been implemented during the > development of the specification. Two public implementations > are available and other company-internal implementations > have been reported to the chairs. Tests have been performed > between two public implementations and useful feedback was > provided to the working group. > > The LoST specification has experienced extensive review, > including reviews by other SDOs. The protocol is an important > building block in the NENA i3 architecture. From wwwrun@core3.amsl.com Wed Jun 11 07:32:52 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.1 required=4.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m5BEVTG9016207 for ; Wed, 11 Jun 2008 07:31:29 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 53AC73A690C; Wed, 11 Jun 2008 07:30:59 -0700 (PDT) From: "Amy Vezza via RT" Reply-To: iesg-secretary@iesg.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #7933 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 11 Jun 2008 07:30:59 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #7933] Resolved: Re: Protocol Action: 'LoST: A Location-to-Service Translation Protocol' to Proposed Standard Status: O X-Status: X-Keywords: $Junk X-UID: 57 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Wed Jun 11 07:33:08 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.1 required=4.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m5BEWEuf016545 for ; Wed, 11 Jun 2008 07:32:15 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 9ABEA3A6936; Wed, 11 Jun 2008 07:31:48 -0700 (PDT) From: "Amy Vezza via RT" Reply-To: iesg-secretary@iesg.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #7932 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 11 Jun 2008 07:31:48 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #7932] Resolved: Re: Document Action: 'Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)' to Informational RFC Status: O X-Status: X-Keywords: $Junk X-UID: 58 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Wed Jun 11 07:34:18 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.1 required=4.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m5BEX0Zc016932 for ; Wed, 11 Jun 2008 07:33:00 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 30FC83A690C; Wed, 11 Jun 2008 07:32:34 -0700 (PDT) From: "Amy Vezza via RT" Reply-To: iesg-secretary@iesg.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #7931 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 11 Jun 2008 07:32:34 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #7931] Resolved: Re: Protocol Action: 'Session Initiation Protocol (SIP) extension for Partial Notification of Presence Information' to Proposed Standard Status: O X-Status: X-Keywords: $Junk X-UID: 59 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Wed Jun 11 13:09:31 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m5BK85hU018900 for ; Wed, 11 Jun 2008 13:08:09 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 2A4143A689A; Wed, 11 Jun 2008 13:07:38 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080611200636.GC16340@isi.edu> References: <20080502193128.GB26096@isi.edu> <20080514190028.GE24579@isi.edu> <20080611200636.GC16340@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #7956 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 11 Jun 2008 13:07:39 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #7956] AutoReply: Re: Informational Independent Submission: draft-santoni-timestampeddata-03.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 60 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Informational Independent Submission: draft-santoni-timestampeddata-03.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #7956]. Please include the string: [rt.amsl.com #7956] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- IESG, We would like to restart the 4 week timeout for (note that the document has been updated to version -04). The OID registration has been resolved (by Russ Housley). This RFC-to-be was submitted to the RFC Editor to be published as Informational: draft-santoni-timestampeddata-04.txt. Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Syntax for binding documents with time stamps This document describes a syntax which can be used to bind a generic document (or any set of data, not necessarily protected by means of cryptographic techniques) to one or more time-stamp tokens obtained for that document, where "time-stamp token" has the meaning defined in RFC 3161. Additional types of temporal evidence are also supported. This document proposes a simple syntax based on the Cryptographic Message Syntax (RFC 3852). Four week timeout expires on 9 July 2008. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents On Wed, May 14, 2008 at 12:00:28PM -0700, RFC Editor wrote: > IESG, > > Please note that a problem has arisen with the OID registration for > this draft, and until it is settled satisfactorily by the author, we > wish to withdraw the draft from TO. > > We apologize for any confusion or inconvenience! > > Thanks, > Sandy > > > On Fri, May 02, 2008 at 12:31:28PM -0700, RFC Editor wrote: > > IESG, > > > > This RFC-to-be was submitted to the RFC Editor to be published as > > Informational: draft-santoni-timestampeddata-03.txt. > > > > Please let us know if this document conflicts with the IETF standards > > process or other work being done in the IETF community. > > > > > > Syntax for binding documents with time stamps > > > > This document describes a syntax which can be used to bind a generic > > document (or any set of data, not necessarily protected by means of > > cryptographic techniques) to one or more time-stamp tokens obtained > > for that document, where "time-stamp token" has the meaning defined > > in RFC 3161. Additional types of temporal evidence are also > > supported. > > > > This document proposes a simple syntax based on the Cryptographic > > Message Syntax (RFC 3852). > > > > > > Four week timeout expires on 30 May 2008. > > > > > > Sincerely, > > > > Sandy Ginoza - USC/ISI > > Request for Comments Documents From wwwrun@core3.amsl.com Wed Jun 11 14:36:38 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m5BLQnBv024425 for ; Wed, 11 Jun 2008 14:26:50 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 7063E3A6957; Wed, 11 Jun 2008 14:26:21 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@iesg.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #7956 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 11 Jun 2008 14:26:22 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #7956] Resolved: Re: Informational Independent Submission: draft-santoni-timestampeddata-03.txt Status: O X-Status: X-Keywords: $Junk X-UID: 61 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Wed Jul 9 15:36:29 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m69MLBmv013530 for ; Wed, 9 Jul 2008 15:21:12 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id AC81E3A6860; Wed, 9 Jul 2008 15:20:57 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080709212043.GB22738@isi.edu> References: <20080709212043.GB22738@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #9195 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 09 Jul 2008 15:20:57 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #9195] AutoReply: Informational Independent Submission: draft-lochter-pkix-brainpool-ecc-01.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 62 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Informational Independent Submission: draft-lochter-pkix-brainpool-ecc-01.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #9195]. Please include the string: [rt.amsl.com #9195] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- IESG, This RFC-to-be was submitted to the RFC Editor to be published as Informational: draft-lochter-pkix-brainpool-ecc-01.txt. Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Five week timeout expires on 13 August 2008. (Please note that we have included an additional week because of the upcoming IETF.) ECC Brainpool Standard Curves and Curve Generation This Memo proposes several elliptic curve domain parameters over finite prime fields for use in cryptographic applications. The domain parameters are consistent with the relevant international standards, and can be used in X.509 certificates and certificate revocation lists (CRLs), for Internet Key Exchange (IKE), Transport Layer Security (TLS), XML signatures, and all applications or protocols based on the cryptographic message syntax (CMS). This document was reviewed by Hal Finney, and his suggestion was incorporated in the -01 version. Finney wrote in review: "This is a very good idea. Present NIST curves do not have proofs that all their parameters are random, a fact which caused trouble when it came time to create the EC RNG in FIPS SP 800-90, as pointed out by Shumow and Ferguson, who found a possible backdoor. NIST curves also are optimized for performance, with field primes that have a lot of 1 bits at the top, allowing for very fast modular arithmetic. However certain techniques along these lines are patented so there is a risk that NIST may be inadvertently leading implementors into legal trouble. Using random primes will avoid this problem. Hopefully performance will still be acceptable.'This is a very good idea. Present NIST curves do not have proofs that all their parameters are random, a fact which caused trouble when it came time to create the EC RNG in FIPS SP 800-90, as pointed out by Shumow and Ferguson, who found a possible backdoor. NIST curves also are optimized for performance, with field primes that have a lot of 1 bits at the top, allowing for very fast modular arithmetic. However certain techniques along these lines are patented so there is a risk that NIST may be inadvertently leading implementors into legal trouble. Using random primes will avoid this problem. Hopefully performance will still be acceptable." Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents From wwwrun@core3.amsl.com Mon Jul 21 09:59:48 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m6LGx9hF021183 for ; Mon, 21 Jul 2008 09:59:10 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id EF1113A6ADD; Mon, 21 Jul 2008 09:58:29 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@iesg.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #9195 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Mon, 21 Jul 2008 09:58:29 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #9195] Resolved: Informational Independent Submission: draft-lochter-pkix-brainpool-ecc-01.txt Status: O X-Status: X-Keywords: $Junk X-UID: 63 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Tue Jul 29 07:27:40 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m6TEQwWA000555 for ; Tue, 29 Jul 2008 07:26:59 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 1770028C1C2; Tue, 29 Jul 2008 07:26:45 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080729142606.GA2367@isi.edu> References: <20080729142606.GA2367@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #9798 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 29 Jul 2008 07:26:46 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #9798] AutoReply: draft-blanchet-v6ops-tunnelbroker-tsp-03.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 64 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "draft-blanchet-v6ops-tunnelbroker-tsp-03.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #9798]. Please include the string: [rt.amsl.com #9798] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- Greetings! Can you please revive the following document: draft-blanchet-v6ops-tunnelbroker-tsp-03.txt Thanks! RFC Editor From wwwrun@core3.amsl.com Tue Aug 5 12:10:47 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m75J9WsK027429 for ; Tue, 5 Aug 2008 12:09:33 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id A595228C314; Tue, 5 Aug 2008 12:09:00 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080805180825.GE18019@isi.edu> References: <20080709212043.GB22738@isi.edu> <20080805180825.GE18019@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #9934 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 05 Aug 2008 12:09:00 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #9934] AutoReply: Re: Informational Independent Submission: draft-lochter-pkix-brainpool-ecc-02.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 65 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Informational Independent Submission: draft-lochter-pkix-brainpool-ecc-02.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #9934]. Please include the string: [rt.amsl.com #9934] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- IESG, Please note that the author has posted a new version of this document. Please be sure to read draft-lochter-pkix-brainpool-ecc-02.txt during your review. Please let us know if you have any questions. Thank you. RFC Editor/sg On Wed, Jul 09, 2008 at 02:20:43PM -0700, RFC Editor wrote: > IESG, > > This RFC-to-be was submitted to the RFC Editor to be published as > Informational: draft-lochter-pkix-brainpool-ecc-01.txt. > > Please let us know if this document conflicts with the IETF standards > process or other work being done in the IETF community. > > Five week timeout expires on 13 August 2008. (Please note that we > have included an additional week because of the upcoming IETF.) > > ECC Brainpool Standard Curves and Curve Generation > > This Memo proposes several elliptic curve domain parameters over > finite prime fields for use in cryptographic applications. The > domain parameters are consistent with the relevant international > standards, and can be used in X.509 certificates and certificate > revocation lists (CRLs), for Internet Key Exchange (IKE), Transport > Layer Security (TLS), XML signatures, and all applications or > protocols based on the cryptographic message syntax (CMS). > > > This document was reviewed by Hal Finney, and his suggestion > was incorporated in the -01 version. Finney wrote in review: > > "This is a very good idea. Present NIST curves do not have proofs that > all their parameters are random, a fact which caused trouble when it > came time to create the EC RNG in FIPS SP 800-90, as pointed out by > Shumow and Ferguson, who found a possible backdoor. NIST curves also > are optimized for performance, with field primes that have a lot of 1 > bits at the top, allowing for very fast modular arithmetic. However > certain techniques along these lines are patented so there is a risk > that NIST may be inadvertently leading implementors into legal trouble. > Using random primes will avoid this problem. Hopefully performance will > still be acceptable.'This is a very good idea. Present NIST curves do > not have proofs that all their parameters are random, a fact which > caused trouble when it came time to create the EC RNG in FIPS SP > 800-90, as pointed out by Shumow and Ferguson, who found a possible > backdoor. NIST curves also are optimized for performance, with field > primes that have a lot of 1 bits at the top, allowing for very fast > modular arithmetic. However certain techniques along these lines are > patented so there is a risk that NIST may be inadvertently leading > implementors into legal trouble. Using random primes will avoid this > problem. Hopefully performance will still be acceptable." > > > Sincerely, > > Sandy Ginoza - USC/ISI > Request for Comments Documents From wwwrun@core3.amsl.com Wed Aug 13 09:32:22 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m7DGVHg0019503 for ; Wed, 13 Aug 2008 09:31:18 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 7E2C228C0D7; Wed, 13 Aug 2008 09:31:12 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080813162851.GA5935@isi.edu> References: <20080813162851.GA5935@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #10052 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 13 Aug 2008 09:31:12 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #10052] AutoReply: Informational IRTF Submission: draft-irtf-nmrg-snmp-measure-05.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 66 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Informational IRTF Submission: draft-irtf-nmrg-snmp-measure-05.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #10052]. Please include the string: [rt.amsl.com #10052] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- IESG, This IRTF RFC-to-be was submitted to the RFC Editor to be published as Informational: draft-irtf-nmrg-snmp-measure-05.txt Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Four week timeout expires on 10 September 2008. SNMP Traffic Measurements and Trace Exchange Formats The Simple Network Management Protocol (SNMP) is widely deployed to monitor, control and (sometimes also) configure network elements. Even though the SNMP technology is well documented, it remains relatively unclear how SNMP is used in practice and what typical SNMP usage patterns are. This document describes an approach to carrying out large scale SNMP traffic measurements in order to develop a better understanding how SNMP is used in real world production networks. It describes the motivation, the measurement approach, and the tools and data formats needed to carry out such a study. This document was produced within the IRTF's Network Management Research Group (NMRG) and represents the consensus of all of the active contributors to this group. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents ----- Forwarded message from Aaron Falk ----- Cc: Internet Research Steering Group , Bert Wijnen From: Aaron Falk To: RFC Editor Subject: Request to publish draft-irtf-nmrg-snmp-measure-05 as Informational RFC Date: Thu, 31 Jul 2008 14:49:56 +0100 Dear RFC Editor- Please publish the above-named document as an Informational RFC from the IRTF. See below for more information. Bert Wijnen is the shepherd, please be sure to copy him on any correspondence related to this document (in addition to the authors, of course). --aaron Begin forwarded message: >From: "Bert Wijnen \(IETF\)" >Date: July 31, 2008 2:33:39 PM BST >To: "Aaron Falk" >Cc: "IRSG" >Subject: Request to publish draft-irtf-nmrg-snmp-measure-05 as >Informational RFC > >Arron, this is a request to publish this document as an >Informational RFC. > >The NMRG has gone through a number of review stages. Also individuals >who are know to be active in this space have been approached for >review. >This is all recorded in the issue tracker under ticket #9, see: > > http://www3.tools.ietf.org/group/irtf/trac/ticket/9 > >Summary of review: > - 15 reviews were recieved on this document during NMRG review >period. > this led to explanation from the author and to a few revisions to > include the required changes/clarifications. > - Each revision was posted and the NMRG has had time to review and > further comment. > - OPS AREA Director Dan Romascanu did issue an IETF Last Call on > revision 3 of this document because it DOES ask for a URI >registration > by IANA. No objections/comments were received. > - revision 4 was also reviewed by Karin R. Sollins which led to one >more > revision, the final revision (05) > - The final revision (05) was reviewed by the IRSG members > Karin R. Sollins and Stephen Farrell; They both voted YES on >the IRSG Poll for this revision. No objections were received. > >I have updated the status to: IRSG review concluded. > >Let me know if I need to do anything else. > >Bert Wijnen >Document Shepherd > ----- End forwarded message ----- From wwwrun@core3.amsl.com Wed Aug 13 09:34:03 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m7DGXDoL020282 for ; Wed, 13 Aug 2008 09:33:14 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 11C1528C0EE; Wed, 13 Aug 2008 09:33:08 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080813162851.GA5935@isi.edu> References: <20080813162851.GA5935@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #10053 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 13 Aug 2008 09:33:09 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #10053] AutoReply: Informational IRTF Submission: draft-irtf-nmrg-snmp-measure-05.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 67 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Informational IRTF Submission: draft-irtf-nmrg-snmp-measure-05.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #10053]. Please include the string: [rt.amsl.com #10053] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- IESG, This IRTF RFC-to-be was submitted to the RFC Editor to be published as Informational: draft-irtf-nmrg-snmp-measure-05.txt Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Four week timeout expires on 10 September 2008. SNMP Traffic Measurements and Trace Exchange Formats The Simple Network Management Protocol (SNMP) is widely deployed to monitor, control and (sometimes also) configure network elements. Even though the SNMP technology is well documented, it remains relatively unclear how SNMP is used in practice and what typical SNMP usage patterns are. This document describes an approach to carrying out large scale SNMP traffic measurements in order to develop a better understanding how SNMP is used in real world production networks. It describes the motivation, the measurement approach, and the tools and data formats needed to carry out such a study. This document was produced within the IRTF's Network Management Research Group (NMRG) and represents the consensus of all of the active contributors to this group. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents ----- Forwarded message from Aaron Falk ----- Cc: Internet Research Steering Group , Bert Wijnen From: Aaron Falk To: RFC Editor Subject: Request to publish draft-irtf-nmrg-snmp-measure-05 as Informational RFC Date: Thu, 31 Jul 2008 14:49:56 +0100 Dear RFC Editor- Please publish the above-named document as an Informational RFC from the IRTF. See below for more information. Bert Wijnen is the shepherd, please be sure to copy him on any correspondence related to this document (in addition to the authors, of course). --aaron Begin forwarded message: >From: "Bert Wijnen \(IETF\)" >Date: July 31, 2008 2:33:39 PM BST >To: "Aaron Falk" >Cc: "IRSG" >Subject: Request to publish draft-irtf-nmrg-snmp-measure-05 as >Informational RFC > >Arron, this is a request to publish this document as an >Informational RFC. > >The NMRG has gone through a number of review stages. Also individuals >who are know to be active in this space have been approached for >review. >This is all recorded in the issue tracker under ticket #9, see: > > http://www3.tools.ietf.org/group/irtf/trac/ticket/9 > >Summary of review: > - 15 reviews were recieved on this document during NMRG review >period. > this led to explanation from the author and to a few revisions to > include the required changes/clarifications. > - Each revision was posted and the NMRG has had time to review and > further comment. > - OPS AREA Director Dan Romascanu did issue an IETF Last Call on > revision 3 of this document because it DOES ask for a URI >registration > by IANA. No objections/comments were received. > - revision 4 was also reviewed by Karin R. Sollins which led to one >more > revision, the final revision (05) > - The final revision (05) was reviewed by the IRSG members > Karin R. Sollins and Stephen Farrell; They both voted YES on >the IRSG Poll for this revision. No objections were received. > >I have updated the status to: IRSG review concluded. > >Let me know if I need to do anything else. > >Bert Wijnen >Document Shepherd > ----- End forwarded message ----- From wwwrun@core3.amsl.com Wed Aug 13 10:47:36 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m7DHkoBd022042 for ; Wed, 13 Aug 2008 10:46:51 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id ABC233A6A9C; Wed, 13 Aug 2008 10:46:39 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@iesg.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #10053 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 13 Aug 2008 10:46:39 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #10053] Resolved: Informational IRTF Submission: draft-irtf-nmrg-snmp-measure-05.txt Status: O X-Status: X-Keywords: $Junk X-UID: 68 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From root@core3.amsl.com Mon Aug 18 10:45:47 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.0 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m7IHjKvs028977 for ; Mon, 18 Aug 2008 10:45:21 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 0) id 504E83A67DB; Mon, 18 Aug 2008 10:45:01 -0700 (PDT) From: IESG Secretary To: rfc-editor@rfc-editor.org Cc: iesg@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20080818174512.504E83A67DB@core3.amsl.com> Date: Mon, 18 Aug 2008 10:45:02 -0700 (PDT) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: root@core3.amsl.com Subject: RFC 3032 updated by RFCs 3270 and 5129 Status: O X-Status: X-Keywords: $Junk X-UID: 69 To: RFC Editor The IESG approved marking RFC 3032 as being updated by RFCs 3270 and 5129 (and vice versa). Best regards, IESG Secretary From wwwrun@core3.amsl.com Tue Aug 19 09:45:15 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m7JGhLBx015965 for ; Tue, 19 Aug 2008 09:43:22 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id A5E923A68B2; Tue, 19 Aug 2008 09:43:12 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@iesg.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #9798 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 19 Aug 2008 09:43:12 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #9798] Resolved: draft-blanchet-v6ops-tunnelbroker-tsp-03.txt Status: O X-Status: X-Keywords: $Junk X-UID: 70 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Tue Aug 26 12:10:57 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m7QJ9C4G015693 for ; Tue, 26 Aug 2008 12:09:13 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 125CD3A69F3; Tue, 26 Aug 2008 12:09:10 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080826190734.GC13193@isi.edu> References: <20080826190734.GC13193@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #10228 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 26 Aug 2008 12:09:10 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #10228] AutoReply: Informational Independent Submission: draft-templin-autoconf-dhcp-16.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 71 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Informational Independent Submission: draft-templin-autoconf-dhcp-16.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #10228]. Please include the string: [rt.amsl.com #10228] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- IESG, This RFC-to-be was submitted to the RFC Editor to be published as Informational: draft-templin-autoconf-dhcp-16.txt Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Four week timeout expires on 23 September 2008. MANET Autoconfiguration using Virtual Enterprise Traversal (VET) Mobile Ad-hoc Networks (MANETs) connect routers on links with asymmetric reachability characteristics, and may also connect to other networks including the Internet. Routers in MANETs must have a way to automatically provision IP addresses/prefixes and other information. This document specifies a Virtual Enterprise Traversal (VET) abstraction for autoconfiguration and operation of routers in MANETs. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents From wwwrun@core3.amsl.com Tue Aug 26 12:15:29 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m7QJCaPx017731 for ; Tue, 26 Aug 2008 12:12:37 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 3E6173A6BEB; Tue, 26 Aug 2008 12:12:34 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080826190931.GD13193@isi.edu> References: <20080826190931.GD13193@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #10229 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 26 Aug 2008 12:12:34 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #10229] AutoReply: Experimental Independent Submission: draft-templin-seal-23.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 72 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Experimental Independent Submission: draft-templin-seal-23.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #10229]. Please include the string: [rt.amsl.com #10229] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- IESG, This RFC-to-be was submitted to the RFC Editor to be published as Experimental: draft-templin-seal-23.txt Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Four week timeout expires on 23 September 2008. The Subnetwork Encapsulation and Adaptation Layer (SEAL) For the purpose of this document, subnetworks are defined as virtual topologies that span connected network regions bounded by encapsulated border nodes. These virtual topologies may span multiple IP- and/or sub-IP layer forwarding hops, and can introduce failure modes due to packet duplication and/or links with diverse Maximum Transmission Units (MTUs). This document specifies a Subnetwork Encapsulation and Adaptation Layer (SEAL) that accommodates such virtual topologies over diverse underlying link technologies. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents From wwwrun@core3.amsl.com Tue Aug 26 12:22:18 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m7QJL5C5023227 for ; Tue, 26 Aug 2008 12:21:06 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 3E8423A6BFC; Tue, 26 Aug 2008 12:21:03 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080826191311.GE13193@isi.edu> References: <20080826191311.GE13193@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #10230 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 26 Aug 2008 12:21:03 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #10230] AutoReply: Experimental Independent Submission: draft-hajjeh-tls-identity-protection-05.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 73 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Experimental Independent Submission: draft-hajjeh-tls-identity-protection-05.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #10230]. Please include the string: [rt.amsl.com #10230] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- IESG, This RFC-to-be was submitted to the RFC Editor to be published as Experimental: draft-hajjeh-tls-identity-protection-05.txt Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Four week timeout expires on 23 September 2008. Credential Protection Ciphersuites for Transport Layer Security (TLS) The Transport Layer Security (TLS) supports three authentication modes: authentication of both parties, server authentication with an unauthenticated client, and total anonymity. For each mode, TLS specifies a set of cipher suites. Whenever the server is authenticated, the channel is secure against man-in-the-middle attacks, but completely anonymous sessions are inherently vulnerable to such attacks. The authentication is usually based on either preshared keys or public key certificates. If a public key certificate is used to authenticate the TLS client during the TLS Handshake, the TLS client credentials are sent in clear text over the wire. Thus, any observer can determine the credentials used by the client, learn who is reaching the network, when, and from where, and hence correlate the client credentials to the connection location. This document defines a set of cipher suites to add client credential protection to the TLS protocol. This is useful especially if TLS is used in wireless environments or to secure remote access. By negotiating one of the ciphersuites described in this document, the TLS clients will be able to determine for themselves when, how, to what extent and for what purpose information about them is communicated to others. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents From wwwrun@core3.amsl.com Tue Aug 26 13:23:58 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m7QKLOmo029836 for ; Tue, 26 Aug 2008 13:21:25 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id E210D28C252; Tue, 26 Aug 2008 13:21:21 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@iesg.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #10228 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 26 Aug 2008 13:21:21 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #10228] Resolved: Informational Independent Submission: draft-templin-autoconf-dhcp-16.txt Status: O X-Status: X-Keywords: $Junk X-UID: 74 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Tue Aug 26 13:25:45 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m7QKNven001276 for ; Tue, 26 Aug 2008 13:23:58 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 520323A6C07; Tue, 26 Aug 2008 13:23:54 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@iesg.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #10229 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 26 Aug 2008 13:23:55 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #10229] Resolved: Experimental Independent Submission: draft-templin-seal-23.txt Status: O X-Status: X-Keywords: $Junk X-UID: 75 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Tue Aug 26 13:31:22 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m7QKTlLg004677 for ; Tue, 26 Aug 2008 13:29:48 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 7F46B3A6C0B; Tue, 26 Aug 2008 13:29:45 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@iesg.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #10230 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 26 Aug 2008 13:29:45 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #10230] Resolved: Experimental Independent Submission: draft-hajjeh-tls-identity-protection-05.txt Status: O X-Status: X-Keywords: $Junk X-UID: 76 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Tue Aug 26 16:58:02 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m7QNvQd0006134 for ; Tue, 26 Aug 2008 16:57:27 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id B380F3A6C4D; Tue, 26 Aug 2008 16:57:22 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080826235547.GF13193@isi.edu> References: <20080826190931.GD13193@isi.edu> <3525C9833C09ED418C6FD6CD9514668C048BEAF2@emailwf1.jnpr.net> <20080826235547.GF13193@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #10234 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 26 Aug 2008 16:57:22 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #10234] AutoReply: Re: Experimental Independent Submission: draft-templin-seal-23.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 77 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Experimental Independent Submission: draft-templin-seal-23.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #10234]. Please include the string: [rt.amsl.com #10234] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- Hi Ross, This works for the RFC Editor. Thanks for keeping us informed! Sandy On Tue, Aug 26, 2008 at 07:44:09PM -0400, Ross Callon wrote: > I would like one additional week to consider this, so that I can put it > onto the IESG agenda for September 25, and reply to the RFC editor by > September 30th. > > Is this okay? > > Thanks, Ross > > -----Original Message----- > From: iesg-bounces@iesg.org [mailto:iesg-bounces@iesg.org] On Behalf Of > RFC Editor > Sent: 26 August 2008 15:10 > To: IESG; iesg-secretary > Cc: fltemplin@acm.org; RFC Editor > Subject: Experimental Independent Submission: draft-templin-seal-23.txt > > IESG, > > This RFC-to-be was submitted to the RFC Editor to be published as > Experimental: draft-templin-seal-23.txt > > Please let us know if this document conflicts with the IETF standards > process or other work being done in the IETF community. > > Four week timeout expires on 23 September 2008. > > > The Subnetwork Encapsulation and Adaptation Layer (SEAL) > > For the purpose of this document, subnetworks are defined as > virtual topologies that span connected network regions bounded by > encapsulated border nodes. These virtual topologies may span > multiple IP- and/or sub-IP layer forwarding hops, and can introduce > failure modes due to packet duplication and/or links with diverse > Maximum Transmission Units (MTUs). This document specifies a > Subnetwork Encapsulation and Adaptation Layer (SEAL) that > accommodates such virtual topologies over diverse underlying link > technologies. > > > Sincerely, > > Sandy Ginoza - USC/ISI > Request for Comments Documents From wwwrun@core3.amsl.com Fri Aug 29 11:55:35 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m7TIsIou029716 for ; Fri, 29 Aug 2008 11:54:19 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 7096428C113; Fri, 29 Aug 2008 11:54:14 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080829185242.GA21874@isi.edu> References: <20080829185242.GA21874@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #10289 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 29 Aug 2008 11:54:14 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #10289] AutoReply: Resubmit -- Informational Independent Submission: draft-saleem-msml-07.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 78 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Resubmit -- Informational Independent Submission: draft-saleem-msml-07.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #10289]. Please include the string: [rt.amsl.com #10289] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- IESG, This document was submitted to the RFC Editor to be published as an Informational Independent Submission: draft-saleem-msml-07.txt. Please note that the IESG has previously requested a 6-month delay in publication (see email below): 3. The IESG thinks that publication is harmful to the IETF work done in the MEDIACTRL WG and recommends not publishing the document at this time. The MEDIACTRL chairs feel that this work directly competes with ongoing work in their group. We are resubmitting this document for an RFC 3932 IESG review. Four week timeout expires on 26 September 2008. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents On Mon, Sep 24, 2007 at 08:29:11PM -0400, The IESG wrote: > The IESG recommends that 'Media Server Markup Language (MSML)' > NOT be published as an an Informational RFC. > > The IESG contact person is Jon Peterson. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-saleem-msml-05.txt > > > The process for such documents is described at http://www.rfc-editor.org/indsubs.html. > > Thank you, > > The IESG Secretary > > Technical Summary > > This specification describes the Media Server Markup Language (MSML), a > language used to control and invoke a variety of services on media servers > used to support real-time communications. Common examples would be > conference services for audio and/or video bridges and interactive voice > response (IVR) systems. > > Working Group Summary > > This document is not a product of an IETF working group; it is an > individual submission via the RFC-Editor. > > Protocol Quality > > Jon Peterson performed the RFC3932 review of this document in conjunction > with the chairs of the MEDIACTRL working group. > > Note to RFC Editor > > Please use the following standard IESG note: > > This RFC is not a candidate for any level of Internet Standard. > The IETF disclaims any knowledge of the fitness of this RFC for > any purpose and in particular notes that the decision to publish > is not based on IETF review for such things as security, > congestion control, or inappropriate interaction with deployed > protocols. The RFC Editor has chosen to publish this document at > its discretion. Readers of this document should exercise caution > in evaluating its value for implementation and deployment. See > RFC 3932 for more information. > > IESG Note > > The IESG recommends the following: > > 3. The IESG thinks that publication is harmful to the IETF work done > in the MEDIACTRL WG and recommends not publishing the document at > this time. > > The MEDIACTRL chairs feel that this work directly competes with ongoing > work in their group. From wwwrun@core3.amsl.com Fri Aug 29 14:10:18 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m7TL9MAE026599 for ; Fri, 29 Aug 2008 14:09:23 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 6C69228C151; Fri, 29 Aug 2008 14:09:18 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080829210815.GB21874@isi.edu> References: <20080829210815.GB21874@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #10291 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 29 Aug 2008 14:09:18 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #10291] AutoReply: Informtional Independent Submission: draft-leung-mip4-proxy-mode-09.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 79 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Informtional Independent Submission: draft-leung-mip4-proxy-mode-09.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #10291]. Please include the string: [rt.amsl.com #10291] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- IESG, This document was submitted to the RFC Editor to be published as an Informational Independent Submission: draft-leung-mip4-proxy-mode-09.txt. Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Four week timeout expires on 26 September 2008. WiMAX Forum/3GPP2 Proxy Mobile IPv4 Mobile IPv4 is a standard mobility protocol that enables IPv4 device to move among networks while maintaining its IP address. The mobile device has the Mobile IPv4 client function to signal its location to the routing anchor, known as the Home Agent. However, there are many IPv4 devices without such capability due to various reasons. This document describes Proxy Mobile IPv4 (PMIPv4), a scheme based on having the Mobile IPv4 client function in a network entity to provide mobility support for an unaltered and mobility-unaware IPv4 device. This document also describes a particular application of PMIPv4 as specified in the WiMAX Forum and another application that is to be adopted in 3GPP2. This independent submision was reviewed by George Tsirtsis. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents From wwwrun@core3.amsl.com Fri Aug 29 15:05:27 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m7TM4ST2015424 for ; Fri, 29 Aug 2008 15:04:29 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 0C7FF28C158; Fri, 29 Aug 2008 15:04:23 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@iesg.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #10291 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 29 Aug 2008 15:04:24 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #10291] Resolved: Informtional Independent Submission: draft-leung-mip4-proxy-mode-09.txt Status: O X-Status: X-Keywords: $Junk X-UID: 80 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Tue Sep 9 11:06:32 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m89I5j13008374 for ; Tue, 9 Sep 2008 11:05:46 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 4F0D23A6A18; Tue, 9 Sep 2008 11:05:40 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20080909180435.GB24294@isi.edu> References: <20080909180435.GB24294@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #10539 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 09 Sep 2008 11:05:40 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #10539] AutoReply: Informational Independent Submission: draft-touch-msword-template-v2.0-07.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 81 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Informational Independent Submission: draft-touch-msword-template-v2.0-07.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #10539]. Please include the string: [rt.amsl.com #10539] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- IESG, This document was submitted to the RFC Editor to be published as an Informational Independent Submission: draft-touch-msword-template-v2.0-07.txt Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Four week timeout expires on 7 October 2008. Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs This document describes the properties and use of a revised Microsoft Word template (.dot) for writing Internet Drafts and RFCs. It updates the initial template described in RFC 3285 to more fully support Word's outline modes and to be easier to use. This template can be direct-printed and direct-viewed, where either is line-for-line identical with RFC Editor-compliant ASCII output. This version is intended as an update to RFC3285. The most recent version of this template and post-processing scripts are available at http://www.isi.edu/touch/tools This document was reviewed for the RFC Editor ("Independent Submissions Editor") by Mike Garhns. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents From wwwrun@core3.amsl.com Wed Oct 1 15:27:36 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m91MQpIS001966 for ; Wed, 1 Oct 2008 15:26:52 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 5C4633A68A1; Wed, 1 Oct 2008 15:26:25 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20081001222534.GH11365@isi.edu> References: <20081001222534.GH11365@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #10876 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 01 Oct 2008 15:26:26 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #10876] AutoReply: Informational Independent Submission: draft-bberry-rfc4938bis-00.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 82 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Informational Independent Submission: draft-bberry-rfc4938bis-00.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #10876]. Please include the string: [rt.amsl.com #10876] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- IESG, This document was submitted to the RFC Editor to be published as an Informational Independent Submission: draft-bberry-rfc4938bis-00.txt. Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Four week timeout expires on 29 October 2008. PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics This document extends the Point-to-Point over Ethernet (PPPoE) Protocol with an optional credit-based flow control mechanism and an optional Link Quality Metric report. These optional extensions improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile point-to-point radio links. This document is a minor extension to RFC 4938, to provide scaling of several fields. The RFC Editor expects that the IESG will want to attach the same IESG disclaimer to this document that they attached to 4938. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents From wwwrun@core3.amsl.com Thu Oct 2 14:38:35 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m92LbNUN019076 for ; Thu, 2 Oct 2008 14:37:24 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id A8E373A6A81; Thu, 2 Oct 2008 14:36:55 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@iesg.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #10876 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 02 Oct 2008 14:36:55 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #10876] Resolved: Informational Independent Submission: draft-bberry-rfc4938bis-00.txt Status: O X-Status: X-Keywords: $Junk X-UID: 83 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Tue Oct 21 13:41:07 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00, DNS_FROM_SECURITYSAGE autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9LKeii2021982 for ; Tue, 21 Oct 2008 13:40:45 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 2FB8828C194; Tue, 21 Oct 2008 13:39:28 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20081021203952.GA9003@isi.edu> References: <20081021203952.GA9003@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #11184 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 21 Oct 2008 13:39:29 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #11184] AutoReply: Expired Internet Drafts vs. I-D Exists Status: O X-Status: X-Keywords: $NotJunk X-UID: 84 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Expired Internet Drafts vs. I-D Exists", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #11184]. Please include the string: [rt.amsl.com #11184] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- Hi All, There has been some discussion on how to cite expired internet-drafts on the rfc-interest list recently (please see http://mailman.rfc-editor.org/pipermail/rfc-interest/2008-October/thread.html for details -- subject: citing historic internet drafts). While doing some research, one of our editors came across what looks like an inconsistency between the Internet-Drafts Database and the I-D Tracker. Using the Internet-Drafts Database shows the I-D Status is Expired, and the I-D Tracker State is I-D Exists; however, the I-D Tracker can't find the document at all. Is this a bug? For example (using a random expired I-D name -- draft-allen-newsml-urn-rfc3085bis): https://datatracker.ietf.org/drafts/ shows the related doc info, but does not allow you to find the actual document: # View Related Documents (e.g., documents that replaced or were replaced by the subject I-D, and their derivatives and precursors.) # I-D Title: URN Namespace for NewsML Resources # I-D Status: Expired # I-D Intended Status at Publication: None # RFC Number: # I-D Tracker State: I-D Exists # Abstract: This document describes a URN (Uniform Resource Name) namespace for identifying NewsML NewsItems and NewsML related XML Schemas. A NewsItem is an information resource that is expressible as a NewsML element within a NewsML document conforming to the NewsML Document Type Declaration (DTD) as defined by the International Press Tele- communications Council (IPTC). # Author(s): The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid. If you are an author of this Internet-Draft, and if your e-mail address is not correct, then please send your current e-mail address to ietf-action@ietf.org. Danny Allen https://datatracker.ietf.org/idtracker/ shows the following error message: No matches to your query. FYI: this doesn't have any bearing (afaict) on the outcome of the discussion. We just thought we would point it out in case your to-do list ever runs low! ;) Thanks! Sandy From wwwrun@core3.amsl.com Fri Oct 24 14:52:05 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_20, DNS_FROM_SECURITYSAGE autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9OLpVll018307 for ; Fri, 24 Oct 2008 14:51:32 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id C0E3328C186; Fri, 24 Oct 2008 14:50:08 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20081024215040.GD26288@isi.edu> References: <20081024215040.GD26288@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #11234 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 24 Oct 2008 14:50:08 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #11234] AutoReply: RFC Online -- rfc616.txt Status: O X-Status: X-Keywords: $NotJunk X-UID: 85 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "RFC Online -- rfc616.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #11234]. Please include the string: [rt.amsl.com #11234] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- Greetings, Please note that a text file for RFC 616 has been added to our repository. rfc616.txt Please let us know if you have any questions. Thank you. RFC Editor From wwwrun@core3.amsl.com Fri Oct 24 15:01:15 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_05, DNS_FROM_SECURITYSAGE autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9OM0gLt021261 for ; Fri, 24 Oct 2008 15:00:43 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id ABF8F3A69C4; Fri, 24 Oct 2008 14:59:19 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20081024220026.GE26288@isi.edu> References: <20081024220026.GE26288@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #11235 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 24 Oct 2008 14:59:19 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #11235] AutoReply: RFC Online -- text files Status: O X-Status: X-Keywords: $NotJunk X-UID: 86 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "RFC Online -- text files", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #11235]. Please include the string: [rt.amsl.com #11235] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- Greetings, Please note that the following documents were added earlier this year (around June), but we had not notified you. Please update your site as necessary. rfc158.txt rfc169.txt rfc320.txt rfc452.txt rfc493.txt rfc497.txt rfc519.txt rfc556.txt rfc557.txt rfc560.txt rfc562.txt rfc571.txt rfc573.txt rfc574.txt rfc587.txt rfc667.txt Thanks! Sandy From wwwrun@core3.amsl.com Tue Oct 28 15:57:57 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_00, DNS_FROM_SECURITYSAGE,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9SMvEhJ029668 for ; Tue, 28 Oct 2008 15:57:15 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 1E43D3A6970; Tue, 28 Oct 2008 15:57:14 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20081028225604.GD20415@isi.edu> References: <20081028174530.931B228C335@core3.amsl.com> <20081028225604.GD20415@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #11307 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 28 Oct 2008 15:57:15 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #11307] AutoReply: Re: Protocol Action: 'CAPWAP Access Controller DHCP Option' to Proposed Standard Status: O X-Status: X-Keywords: $NotJunk X-UID: 87 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'CAPWAP Access Controller DHCP Option' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #11307]. Please include the string: [rt.amsl.com #11307] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Tue, Oct 28, 2008 at 10:45:30AM -0700, The IESG wrote: > The IESG has approved the following document: > > - 'CAPWAP Access Controller DHCP Option ' > as a Proposed Standard > > This document is the product of the Control And Provisioning of Wireless > Access Points Working Group. > > The IESG contact persons are Dan Romascanu and Ron Bonica. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-capwap-dhc-ac-option-02.txt > > Technical Summary > > The Control And Provisioning of Wireless Access Points Protocol > allows a Wireless Termination Point to use DHCP to discover the > Access Controllers it is to connect to. This document describes the > DHCP options to be used by the CAPWAP protocol. > > Working Group Summary > > This document is a work item of the CAPWAP WG and respresents > the consensus of the group. > > Document Quality > > This document was reviewed within the CAPWAP WG and no issues > were raised in WG Last Call. Francis Dupont reviewed it for the GenART > and Dan Romascanu performed the OPS Area Director review. > > Personnel > > Margaret Wasserman is the document shepherd and Dan Romascanu is the > responsible AD. From wwwrun@core3.amsl.com Tue Oct 28 15:58:04 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=AWL,BAYES_00, DNS_FROM_SECURITYSAGE,SUBJ_HAS_SPACES,SUBJ_HAS_UNIQ_ID autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9SMvLWw029694 for ; Tue, 28 Oct 2008 15:57:22 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 9387A3A6968; Tue, 28 Oct 2008 15:57:21 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20081028225624.GE20415@isi.edu> References: <20081027220207.DEEF83A6A2C@core3.amsl.com> <20081028225624.GE20415@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #11308 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 28 Oct 2008 15:57:21 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #11308] AutoReply: Re: Document Action: 'Requirements for Management of Overload in the Session Initiation Protocol' to Informational RFC Status: O X-Status: X-Keywords: $NotJunk X-UID: 88 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'Requirements for Management of Overload in the Session Initiation Protocol' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #11308]. Please include the string: [rt.amsl.com #11308] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Mon, Oct 27, 2008 at 03:02:07PM -0700, The IESG wrote: > The IESG has approved the following document: > > - 'Requirements for Management of Overload in the Session Initiation > Protocol ' > as an Informational RFC > > This document is the product of the Session Initiation Proposal > Investigation Working Group. > > The IESG contact persons are Jon Peterson and Cullen Jennings. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sipping-overload-reqs-05.txt > > Technical Summary > > Overload occurs in Session Initiation Protocol (SIP) networks when > proxies and user agents have insuffient resources to complete the > processing of a request. SIP provides limited support for overload > handling through its 503 response code, which tells an upstream > element that it is overloaded. However, numerous problems have been > identified with this mechanism. This draft summarizes the problems > with the existing 503 mechanism, and provides some requirements for a > solution. > > Working Group Summary > > The SIPPING WG supports the development and advancement of > this document. > > Document Quality > > This document defines no new protocol elements. The document has been > thoroughly reviewed by members of the SIPPING WG and members of the design > team working on modeling and simulations for SIP overload. > > > Personnel > > Jon Peterson reviewed this document for the IESG. Mary Barnes in the > document shepherd. > > RFC Editor Note > > In the Security Considerations, please append the following paragraph: > > Any mechanism that improves the behavior of SIP elements under load > will result in more predictable performance in the face of > application-layer denial-of-service attacks. From wwwrun@core3.amsl.com Tue Oct 28 16:04:27 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: * X-Spam-Status: No, score=1.2 required=5.0 tests=AWL,BAYES_50, DNS_FROM_SECURITYSAGE,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9SN3naC002528 for ; Tue, 28 Oct 2008 16:03:50 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 0FAB73A6C96; Tue, 28 Oct 2008 16:03:49 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@iesg.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #11307 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 28 Oct 2008 16:03:50 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #11307] Resolved: Re: Protocol Action: 'CAPWAP Access Controller DHCP Option' to Proposed Standard Status: O X-Status: X-Keywords: $Junk X-UID: 89 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Tue Oct 28 16:07:43 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=AWL,BAYES_20, DNS_FROM_SECURITYSAGE,SUBJ_HAS_SPACES,SUBJ_HAS_UNIQ_ID autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9SN7C6B003935 for ; Tue, 28 Oct 2008 16:07:13 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 736B03A6C7F; Tue, 28 Oct 2008 16:07:12 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@iesg.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #11308 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 28 Oct 2008 16:07:12 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #11308] Resolved: Re: Document Action: 'Requirements for Management of Overload in the Session Initiation Protocol' to Informational RFC Status: O X-Status: X-Keywords: $Junk X-UID: 90 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Tue Oct 28 16:09:15 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_00, DNS_FROM_SECURITYSAGE,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9SN8XI2004277 for ; Tue, 28 Oct 2008 16:08:34 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 4AE3A3A6C93; Tue, 28 Oct 2008 16:08:33 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20081028225639.GF20415@isi.edu> References: <20081027190847.3436C3A67D4@core3.amsl.com> <20081028225639.GF20415@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #11309 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 28 Oct 2008 16:08:34 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #11309] AutoReply: Re: Protocol Action: 'Textual Representation of AS Numbers' to Proposed Standard Status: O X-Status: X-Keywords: $NotJunk X-UID: 91 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Textual Representation of AS Numbers' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #11309]. Please include the string: [rt.amsl.com #11309] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Mon, Oct 27, 2008 at 12:08:47PM -0700, The IESG wrote: > The IESG has approved the following document: > > - 'Textual Representation of AS Numbers ' > as a Proposed Standard > > This document is the product of the Inter-Domain Routing Working Group. > > The IESG contact persons are David Ward and Ross Callon. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-idr-as-representation-01.txt > > Technical Summary > > A textual representation for Autonomous System (AS) numbers is > defined as the decimal value of the AS Number. This textual > representation is to be used by all documents, systems and user > interfaces referring to AS numbers. > > > asplain > refers to a syntax scheme of representing all AS numbers using > decimal integer notation. Using asplain notation an AS number of > value 65526 would be represented as the string "65526" and an AS > number of value 65546 would be represented as the string "65546". > > Working Group Summary > > It was readily accepted. > > Document Quality > > No issues > > Personnel > > Dave Ward From wwwrun@core3.amsl.com Tue Oct 28 16:16:52 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=AWL,BAYES_40, DNS_FROM_SECURITYSAGE,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9SNGIvI006908 for ; Tue, 28 Oct 2008 16:16:19 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 308F03A6970; Tue, 28 Oct 2008 16:16:15 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@iesg.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #11309 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 28 Oct 2008 16:16:16 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #11309] Resolved: Re: Protocol Action: 'Textual Representation of AS Numbers' to Proposed Standard Status: O X-Status: X-Keywords: $Junk X-UID: 92 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Wed Oct 29 11:35:14 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_00, DNS_FROM_SECURITYSAGE,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9TIYGxI008004 for ; Wed, 29 Oct 2008 11:34:17 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 7584E28C3BD; Wed, 29 Oct 2008 11:34:16 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@iesg.org In-Reply-To: <20081029183208.GD15253@isi.edu> References: <20081029161324.E6B423A6D3E@core3.amsl.com> <20081029183208.GD15253@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #11331 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 29 Oct 2008 11:34:16 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #11331] AutoReply: Re: Protocol Action: 'Information Model and XML Data Model for Traceroute Measurements' to Proposed Standard Status: O X-Status: X-Keywords: $NotJunk X-UID: 93 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Information Model and XML Data Model for Traceroute Measurements' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #11331]. Please include the string: [rt.amsl.com #11331] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@iesg.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Wed, Oct 29, 2008 at 09:13:24AM -0700, The IESG wrote: > The IESG has approved the following document: > > - 'Information Model and XML Data Model for Traceroute Measurements ' > as a Proposed Standard > > This document is the product of the IP Performance Metrics Working Group. > > The IESG contact persons are Lars Eggert and Magnus Westerlund. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ippm-storetraceroutes-12.txt > > Technical Summary > > This document describes a standard way to store the configuration and > the results of traceroute measurements. This document first of all > describes the tool itself; afterwards, the common information model > is defined dividing the information elements in two semantically > separated groups (configuration elements and results ones). Moreover > an additional element is defined to relate configuration elements and > results ones by means of a common unique identifier. On the basis of > the information model a data model based on XML is defined to store > the results of traceroute measurements. > > Working Group Summary > > The working group has supported the document throughout its life > and it has been uncontroversial. > > Document Quality > > The document has been given thorough review by the group over its > revisions. The XML code has been reviewed by the XML directorate. > > A previous version of this document required significant changes to > address the gen-art review. The document underwent a second > working group last call and IETF last call to verify consensus for > these changes. > > Personnel > > Henk Uijterwaal (henk@ripe.net) was the Document Shepherd. > Ned Freed (ned.freed@mrochek.com) reviewed the document > for the XML Directorate. Lars Eggert (lars.eggert@nokia.com) > reviewed it for the IESG. > > RFC Editor Note > > In the description of the CtlSourceAddress element (bottom of page 29): > > > OLD: > On hosts with more than one IP address, this option can be used to > force the source address to be something other than the primary IP > address of the interface the probe is sent on. If "unknown" is > specified for this object it means that source address specification > was disabled. > > NEW: > On hosts with more than one IP address, this option can be used in > "RequestMetadata" element to force the source address to be something > other than the primary IP address of the interface the probe is sent > on; the value "unknown" means the default address will be used. From wwwrun@core3.amsl.com Wed Oct 29 13:54:45 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=0.9 required=5.0 tests=AWL,BAYES_05, DNS_FROM_SECURITYSAGE,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9TKsCf7019259 for ; Wed, 29 Oct 2008 13:54:13 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 8927A3A6B2D; Wed, 29 Oct 2008 13:54:12 -0700 (PDT) From: "Amy Vezza via RT" Reply-To: iesg-secretary@iesg.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #11331 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 29 Oct 2008 13:54:12 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #11331] Resolved: Re: Protocol Action: 'Information Model and XML Data Model for Traceroute Measurements' to Proposed Standard Status: O X-Status: X-Keywords: $Junk X-UID: 94 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Mon Nov 3 12:30:09 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=0.9 required=5.0 tests=AWL,BAYES_40, DNS_FROM_SECURITYSAGE autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mA3KTdiw028788 for ; Mon, 3 Nov 2008 12:29:40 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id DFC073A6B8F; Mon, 3 Nov 2008 12:29:40 -0800 (PST) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20081103202850.GB28198@isi.edu> References: <20081103202850.GB28198@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #11457 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Mon, 03 Nov 2008 12:29:40 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #11457] AutoReply: Please expire these drafts Status: O X-Status: X-Keywords: $NotJunk X-UID: 95 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Please expire these drafts", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #11457]. Please include the string: [rt.amsl.com #11457] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, Please allow the following documents to expire in the I-D repository: draft-bberry-pppoe-scaled-credits-metrics-01.txt draft-bambenek-doubleflux-01.txt Please let us know if you have any questions. Thank you. RFC Editor From wwwrun@core3.amsl.com Mon Nov 3 12:39:08 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=0.9 required=5.0 tests=AWL,BAYES_40, DNS_FROM_SECURITYSAGE autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mA3KccS5002600 for ; Mon, 3 Nov 2008 12:38:39 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 498CA28C2E6; Mon, 3 Nov 2008 12:38:29 -0800 (PST) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20081103203623.GD28198@isi.edu> References: <20081103203623.GD28198@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #11458 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Mon, 03 Nov 2008 12:38:30 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #11458] AutoReply: Please expire this draft Status: O X-Status: X-Keywords: $NotJunk X-UID: 96 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Please expire this draft", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #11458]. Please include the string: [rt.amsl.com #11458] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, Please allow draft-shore-nls-tl-06.txt to expire. Thank you. RFC Editor From wwwrun@core3.amsl.com Mon Nov 3 15:51:57 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: * X-Spam-Status: No, score=1.0 required=5.0 tests=AWL,BAYES_50, DNS_FROM_SECURITYSAGE autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mA3NpXag018322 for ; Mon, 3 Nov 2008 15:51:34 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 6FAE83A6CB1; Mon, 3 Nov 2008 15:51:32 -0800 (PST) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #11458 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Mon, 03 Nov 2008 15:51:32 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #11458] Resolved: Please expire this draft Status: O X-Status: X-Keywords: $Junk X-UID: 97 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Mon Nov 3 15:53:55 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=AWL,BAYES_50, DNS_FROM_SECURITYSAGE autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mA3Nr5Rb019010 for ; Mon, 3 Nov 2008 15:53:06 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 134B63A6CB2; Mon, 3 Nov 2008 15:53:07 -0800 (PST) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #11457 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Mon, 03 Nov 2008 15:53:07 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #11457] Resolved: Please expire these drafts Status: O X-Status: X-Keywords: $Junk X-UID: 98 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Tue Nov 11 18:05:53 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00, DNS_FROM_SECURITYSAGE,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mAC24bvd017526 for ; Tue, 11 Nov 2008 18:04:38 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id DBE2E3A6A7F; Tue, 11 Nov 2008 18:04:35 -0800 (PST) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20081112020415.GC16949@isi.edu> References: <20081111172037.34D0328C1F2@core3.amsl.com> <20081112020415.GC16949@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #11638 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 11 Nov 2008 18:04:35 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #11638] AutoReply: Re: Protocol Action: 'CAPWAP Protocol Specification' to Proposed Standard Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'CAPWAP Protocol Specification' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #11638]. Please include the string: [rt.amsl.com #11638] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Tue, Nov 11, 2008 at 09:20:37AM -0800, The IESG wrote: > The IESG has approved the following document: > > - 'CAPWAP Protocol Specification ' > as a Proposed Standard > > This document is the product of the Control And Provisioning of Wireless > Access Points Working Group. > > The IESG contact persons are Dan Romascanu and Ron Bonica. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-capwap-protocol-specification-15.txt > > Technical Summary > > This specification defines the Control And Provisioning of Wireless > Access Points (CAPWAP) Protocol. This is a protocol to allow an > Access Controller (AC) to securely manage the firmware and > configuration of a set of Wireless Termination Points (WTPs). > > The CAPWAP protocol meets the IETF CAPWAP working group protocol > requirements. The CAPWAP protocol is designed to be flexible, > allowing it to be used for a variety of wireless technologies. > This document describes the base CAPWAP protocol. The CAPWAP > protocol binding which defines extensions for use with the IEEE > 802.11 wireless LAN protocol is available in a separate document. > Extensions are expected to be defined to enable use of the CAPWAP > protocol with additional wireless technologies. > > Working Group Summary > > This document represents a very strong consensus of the WG. Earlier > there was a lot of contention about different aspects of this > protocol, including (but not limited to) the security model, the basic > operational model, and what parts of the functionality should be > mandatory or optional. However, consensus was reached > on all of those points and that consensus is properly reflected in the > current document. > > Document Quality > > The CAPWAP protocol has been extensively reviewed and has been > updated to address issues raised in those reviewes. Technical > advisors were Charles Clancy, Scott Kelly, Bob O'Hara and David > Borman. Joe Salowey provided an early secdir review, and > Pasi Eronen reviewed again at IETF Last Call. Magnus Westerlund and > Lars Eggert performed an early transport area review. Dan Romascanu > performed the OPS Area Review. The document was also reviewed by > IEEE 802.11. > > Personnel > > Margaret Wasserman is PROTO-shepherd and Dan Romascanu is shepherding > AD. From wwwrun@core3.amsl.com Wed Nov 12 10:40:18 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: * X-Spam-Status: No, score=1.4 required=5.0 tests=AWL,BAYES_50, DNS_FROM_SECURITYSAGE,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mACIddpd020738 for ; Wed, 12 Nov 2008 10:39:40 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 5CBF63A6931; Wed, 12 Nov 2008 10:39:38 -0800 (PST) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #11638 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 12 Nov 2008 10:39:38 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #11638] Resolved: Re: Protocol Action: 'CAPWAP Protocol Specification' to Proposed Standard According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From root@core3.amsl.com Fri Dec 5 08:00:46 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES, SUBJ_HAS_UNIQ_ID autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mB5FxvNG001787 for ; Fri, 5 Dec 2008 07:59:58 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 0) id C89643A67AE; Fri, 5 Dec 2008 08:00:01 -0800 (PST) From: IESG Secretary To: rfc-editor@rfc-editor.org Cc: avezza@amsl.com, cmorgan@amsl.com, iesg@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20081205160001.C89643A67AE@core3.amsl.com> Date: Fri, 5 Dec 2008 08:00:01 -0800 (PST) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: root@core3.amsl.com Subject: Expedited Handling Request for the CAPWAP Protocol Specification (draft-ietf-capwap-protocol-specification) RFC Editor, The IESG approved in a management item discussion in the 12/4 telechat the request to expedite processing of the CAPWAP Protocol Specification (draft-ietf-capwap-protocol-specification) which was recently approved by the IESG. Please do the best that this specification is published until 12/23, or soon after 1/2/2009. Background: An industry standards group, EPCglobal, has a CAPWAP binding, "EPCglobal Discovery, Configuration and Initialization (DCI)" that cannot be published until they have an RFC number for the CAPWAP Protocol Specification. The DCI specification is fully ratified and their final publication has been blocking on the publication of the CAPWAP Protocol Specification since mid-summer. Thanks and Regards, Dan From root@core3.amsl.com Mon Dec 15 11:00:57 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mBFIxttx011480 for ; Mon, 15 Dec 2008 10:59:56 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 0) id 0D02D28C131; Mon, 15 Dec 2008 11:00:01 -0800 (PST) From: IESG Secretary To: rfc-editor@rfc-editor.org Cc: iesg@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20081215190002.0D02D28C131@core3.amsl.com> Date: Mon, 15 Dec 2008 11:00:02 -0800 (PST) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: root@core3.amsl.com Subject: Expedited Handling of draft-ietf-avt-rtp-g719 To the RFC Editor: The IESG has approved expedited publication for draft-ietf-avt-rtp-g719 and the preferred publication date is by January 15, 2009. Thank you. Best regards, IESG Secretary From root@core3.amsl.com Tue Dec 23 13:15:23 2008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES, SUBJ_HAS_UNIQ_ID autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id mBNLEr1X010917 for ; Tue, 23 Dec 2008 13:14:54 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 0) id 989943A6859; Tue, 23 Dec 2008 13:15:01 -0800 (PST) From: IESG Secretary To: rfc-editor@rfc-editor.org Cc: iesg@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20081223211501.989943A6859@core3.amsl.com> Date: Tue, 23 Dec 2008 13:15:01 -0800 (PST) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: root@core3.amsl.com Subject: Expedited publishing request for draft-jerichow-msec-mikey-genext-oma To the RFC Editor, The IESG has approved the request for expedited publishing for draft-jerichow-msec-mikey-genext-oma, with a target date of January 7, 2009, to establish a stable reference for the Open Mobile Alliance to use in their own publications. Thank you, The IESG Secretary From wwwrun@core3.amsl.com Wed Feb 25 13:15:33 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n1PLEitj020353 for ; Wed, 25 Feb 2009 13:14:45 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id AA7F03A6A9E; Wed, 25 Feb 2009 13:14:23 -0800 (PST) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090225211308.GO13275@isi.edu> References: <20090225211308.GO13275@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #13469 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 25 Feb 2009 13:14:23 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #13469] AutoReply: Informational Independent Submission: ID-stringIndependent Submission: draft-farah-adntf-ling-guidelines-04.txt Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Informational Independent Submission: ID-stringIndependent Submission: draft-farah-adntf-ling-guidelines-04.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #13469]. Please include the string: [rt.amsl.com #13469] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- IESG, This document was submitted to the RFC Editor to be published as an Informational Independent Submission: draft-farah-adntf-ling-guidelines-04.txt. Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Five week timeout expires on 1 April 2009. Note that we have included an extra week because of the upcoming IETF. Linguistic Guidelines for the Use of the Arabic Language in Internet Domains This document constitutes technical specifications for the use of Arabic in Internet Domain names and provides linguistic guidelines for Arabic Domain Names. It addresses Arabic-specific linguistic issues pertaining to the use of Arabic language in domain names. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents From wwwrun@core3.amsl.com Thu Feb 26 12:53:41 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n1QKqwPJ002287 for ; Thu, 26 Feb 2009 12:52:59 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 4D26D28C2DB; Thu, 26 Feb 2009 12:52:35 -0800 (PST) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #13469 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 26 Feb 2009 12:52:36 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #13469] Resolved: Informational Independent Submission: ID-stringIndependent Submission: draft-farah-adntf-ling-guidelines-04.txt According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Thu Mar 5 09:44:45 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n25Hi98K009747 for ; Thu, 5 Mar 2009 09:44:10 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id AD78928C3B9; Thu, 5 Mar 2009 09:43:39 -0800 (PST) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090305174320.GB10127@isi.edu> References: <20090305174320.GB10127@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #13665 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 05 Mar 2009 09:43:39 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #13665] AutoReply: Re: PWE mib -- draft-vainshtein-pwe3-tdm-control-protocol-extensi Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: PWE mib -- draft-vainshtein-pwe3-tdm-control-protocol-extensi", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #13665]. Please include the string: [rt.amsl.com #13665] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Hi All! I wasn't sure if this should be sent to you or to webtools@ietf.org, but I thought I'd try you first. I'm also not sure there is any action required, but there seems to be an oddity in the search results for draft-vainshtein-pwe3-tdm-control-protocol-extensi using the Internet-Drafts Database. We were notified that draft-vainshtein-pwe3-tdm-control-protocol-extensi was replaced by draft-ietf-pwe3-tdm-control-protocol-extensi-07, but the results from the Internet-Drafts Database Interface do not show that the draft was replaced. It yields the following: I-D Filename and Version Number draft-vainshtein-pwe3-tdm-control-protocol-extensi-04 Submission Date 2005-07-06 Status Expired RFC # I-D Tracker State I-D Exists It seems that when a draft has been replaced, the Internet-Drafts database usually indicates that the I-D has been replaced? The results were a bit confusing because it lists the Status as Expired, but the I-D Tracker State as I-D Exists, even though the I-D Tracker results in "No matches to your query." Thanks! See you in a couple of weeks! Sandy > On Mar 5, 2009, at 8:22 AM, Orly Nicklass wrote: > > >HI, > > > >I review the publication list and noticed that some of the > >information is not accurate. The not received draft is in the > >repository, I put reference to it. And one is already RFC by now. > > > >Pls advice how to adjust those states correctly > > > > > >2008-07-21 draft-ietf-pwe3-enet-mib-13.txt PLS see new > >draft: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-enet- > >mib-14.txt MISSREFREF draft-ietf-pwe3-pw-mib IN-QUEUE > >draft-ietf-pwe3-pw-tc-mib NOT-RECEIVED pls see: http:// > >www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-tc-mib-15.txtD. > >Zelig, Ed., T. Nadeau, Ed."Ethernet Pseudowire (PW) Management > >Information Base (MIB)"Bytes: 44473Working Group: Pseudo Wire > >Emulation Edge to Edge > > > > > >2008-06-23 draft-ietf-pwe3-pw-mib-14.txtMISSREFREF draft- > >ietf-pwe3-pw-tc-mib NOT-RECEIVED pls see: http:// > >www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-tc-mib-15.txtT. > >Nadeau, Ed., D. Zelig, Ed."Pseudowire (PW) Management Information > >Base (MIB)"Bytes: 128939Working Group: Pseudo Wire Emulation Edge > >to Edge > > > > > >2008-11-18 draft-ietf-pwe3-pw-atm-mib-06.txtMISSREFREF > >draft-ietf-pwe3-pw-tc-mib NOT-RECEIVED pls see: http:// > >www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-tc- > >mib-15.txt draft-ietf-pwe3-pw-mib IN-QUEUE draft-ietf- > >pwe3-pw-mpls-mib IN-QUEUEO. Nicklass, S. Sathappan, M. > >Venkatesan, T. Nadeau"Managed Objects for ATM over Packet Switched > >Network (PSN)"Bytes: 73158Working Group: Pseudo Wire Emulation Edge > >to Edge > > > >2009-02-09 draft-ietf-pwe3-tdm-mib-11.txtMISSREFREF draft- > >vainshtein-pwe3-tdm-control-protocol-extensi NOT-RECEIVED this > >RFC by now: http://www.ietf.org/rfc/rfc5287.txt draft-ietf- > >pwe3-pw-mib IN-QUEUE draft-ietf-pwe3-pw-tc-mib NOT- > >RECEIVED pls see: http://www.ietf.org/internet-drafts/draft-ietf- > >pwe3-pw-tc-mib-15.txtO. Nicklass"Managed Objects for TDM over > >Packet Switched Network (PSN)"Bytes: 81329Working Group: Pseudo > >Wire Emulation Edge to Edge > > > > > >2008-07-21 draft-ietf-pwe3-pw-mpls-mib-14.txtMISSREFREF > >draft-ietf-pwe3-pw-tc-mib NOT-RECEIVED pls see: http:// > >www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-tc- > >mib-15.txt draft-ietf-pwe3-pw-mib IN-QUEUED. Zelig, Ed., T. > >Nadeau, Ed."Pseudowire (PW) over MPLS PSN Management Information > >Base (MIB)"Bytes: 62692Working Group: Pseudo Wire Emulation Edge to > >Edge > > > > > > > > > >Orly Nicklass, Ph.D > >VP R&D, NBU > >RADVISION® > >Delivering the Visual ExperienceTM > >Phone: +97237679444 > >Mobile: 0547769444 > > > ----- End forwarded message ----- From wwwrun@core3.amsl.com Thu Mar 5 11:33:36 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n25JWvI4020139 for ; Thu, 5 Mar 2009 11:32:58 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 7376728C0DD; Thu, 5 Mar 2009 11:32:27 -0800 (PST) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090305174320.GB10127@isi.edu> References: <20090305174320.GB10127@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #13665 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 05 Mar 2009 11:32:27 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #13665] Re: PWE mib -- draft-vainshtein-pwe3-tdm-control-protocol-extensi Hi Sandy, It looks like what happened in this case is that somehow the secretariat missed the message that draft-vainshtein-pwe3-tdm-control-protocol-extensi was replaced by draft-ietf-pwe3-tdm-control-protocol-extensi. That's now been fixed, and so the search results for draft-vainshtein show the draft as being Replaced/ID Exists. Best regards, Cindy On Thu Mar 05 09:43:39 2009, rfc-editor@rfc-editor.org wrote: > Hi All! > > I wasn't sure if this should be sent to you or to webtools@ietf.org, > but I thought I'd try you first. I'm also not sure there is any > action required, but there seems to be an oddity in the search results > for draft-vainshtein-pwe3-tdm-control-protocol-extensi using the > Internet-Drafts Database. > > We were notified that > draft-vainshtein-pwe3-tdm-control-protocol-extensi was replaced by > draft-ietf-pwe3-tdm-control-protocol-extensi-07, but the results from > the Internet-Drafts Database Interface do not show that the draft was > replaced. It yields the following: > > I-D Filename and Version Number > draft-vainshtein-pwe3-tdm-control-protocol-extensi-04 > > Submission Date > 2005-07-06 > > Status > Expired > > RFC # > > I-D Tracker State > I-D Exists > > It seems that when a draft has been replaced, the Internet-Drafts > database usually indicates that the I-D has been replaced? > > The results were a bit confusing because it lists the Status as > Expired, but the I-D Tracker State as I-D Exists, even though the I-D > Tracker results in "No matches to your query." > > Thanks! See you in a couple of weeks! > > Sandy > > > On Mar 5, 2009, at 8:22 AM, Orly Nicklass wrote: > > > > >HI, > > > > > >I review the publication list and noticed that some of the > > >information is not accurate. The not received draft is in the > > >repository, I put reference to it. And one is already RFC by now. > > > > > >Pls advice how to adjust those states correctly > > > > > > > > >2008-07-21 draft-ietf-pwe3-enet-mib-13.txt PLS see new > > >draft: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-enet- > > >mib-14.txt MISSREFREF draft-ietf-pwe3-pw-mib IN-QUEUE > > >draft-ietf-pwe3-pw-tc-mib NOT-RECEIVED pls see: http:// > > >www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-tc-mib-15.txtD. > > >Zelig, Ed., T. Nadeau, Ed."Ethernet Pseudowire (PW) Management > > >Information Base (MIB)"Bytes: 44473Working Group: Pseudo Wire > > >Emulation Edge to Edge > > > > > > > > >2008-06-23 draft-ietf-pwe3-pw-mib-14.txtMISSREFREF draft- > > >ietf-pwe3-pw-tc-mib NOT-RECEIVED pls see: http:// > > >www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-tc-mib-15.txtT. > > >Nadeau, Ed., D. Zelig, Ed."Pseudowire (PW) Management Information > > >Base (MIB)"Bytes: 128939Working Group: Pseudo Wire Emulation Edge > > >to Edge > > > > > > > > >2008-11-18 draft-ietf-pwe3-pw-atm-mib-06.txtMISSREFREF > > >draft-ietf-pwe3-pw-tc-mib NOT-RECEIVED pls see: http:// > > >www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-tc- > > >mib-15.txt draft-ietf-pwe3-pw-mib IN-QUEUE draft-ietf- > > >pwe3-pw-mpls-mib IN-QUEUEO. Nicklass, S. Sathappan, M. > > >Venkatesan, T. Nadeau"Managed Objects for ATM over Packet Switched > > >Network (PSN)"Bytes: 73158Working Group: Pseudo Wire Emulation Edge > > >to Edge > > > > > >2009-02-09 draft-ietf-pwe3-tdm-mib-11.txtMISSREFREF draft- > > >vainshtein-pwe3-tdm-control-protocol-extensi NOT-RECEIVED this > > >RFC by now: http://www.ietf.org/rfc/rfc5287.txt draft-ietf- > > >pwe3-pw-mib IN-QUEUE draft-ietf-pwe3-pw-tc-mib NOT- > > >RECEIVED pls see: http://www.ietf.org/internet-drafts/draft-ietf- > > >pwe3-pw-tc-mib-15.txtO. Nicklass"Managed Objects for TDM over > > >Packet Switched Network (PSN)"Bytes: 81329Working Group: Pseudo > > >Wire Emulation Edge to Edge > > > > > > > > >2008-07-21 draft-ietf-pwe3-pw-mpls-mib-14.txtMISSREFREF > > >draft-ietf-pwe3-pw-tc-mib NOT-RECEIVED pls see: http:// > > >www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-tc- > > >mib-15.txt draft-ietf-pwe3-pw-mib IN-QUEUED. Zelig, Ed., T. > > >Nadeau, Ed."Pseudowire (PW) over MPLS PSN Management Information > > >Base (MIB)"Bytes: 62692Working Group: Pseudo Wire Emulation Edge to > > >Edge > > > > > > > > > > > > > > >Orly Nicklass, Ph.D > > >VP R&D, NBU > > >RADVISION® > > >Delivering the Visual ExperienceTM > > >Phone: +97237679444 > > >Mobile: 0547769444 > > > > > > > ----- End forwarded message ----- > From wwwrun@core3.amsl.com Thu Mar 5 11:59:31 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n25JwjTY029701 for ; Thu, 5 Mar 2009 11:58:46 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id D460C3A6B3F; Thu, 5 Mar 2009 11:58:15 -0800 (PST) Subject: Re: [rt.amsl.com #13665] Re: PWE mib -- draft-vainshtein-pwe3-tdm-control-protocol-extensi From: "RFC Editor via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090305195744.GD10127@isi.edu> References: <20090305174320.GB10127@isi.edu> <20090305195744.GD10127@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #13665 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 05 Mar 2009 11:58:15 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Hi Cindy, Thanks for the info and for the quick response! Sandy On Thu, Mar 05, 2009 at 11:32:27AM -0800, Cindy Morgan via RT wrote: > Hi Sandy, > > It looks like what happened in this case is that somehow the secretariat > missed the message that > draft-vainshtein-pwe3-tdm-control-protocol-extensi was replaced by > draft-ietf-pwe3-tdm-control-protocol-extensi. That's now been fixed, > and so the search results for draft-vainshtein show the draft as being > Replaced/ID Exists. > > Best regards, > Cindy > > > On Thu Mar 05 09:43:39 2009, rfc-editor@rfc-editor.org wrote: > > Hi All! > > > > I wasn't sure if this should be sent to you or to webtools@ietf.org, > > but I thought I'd try you first. I'm also not sure there is any > > action required, but there seems to be an oddity in the search results > > for draft-vainshtein-pwe3-tdm-control-protocol-extensi using the > > Internet-Drafts Database. > > > > We were notified that > > draft-vainshtein-pwe3-tdm-control-protocol-extensi was replaced by > > draft-ietf-pwe3-tdm-control-protocol-extensi-07, but the results from > > the Internet-Drafts Database Interface do not show that the draft was > > replaced. It yields the following: > > > > I-D Filename and Version Number > > draft-vainshtein-pwe3-tdm-control-protocol-extensi-04 > > > > Submission Date > > 2005-07-06 > > > > Status > > Expired > > > > RFC # > > > > I-D Tracker State > > I-D Exists > > > > It seems that when a draft has been replaced, the Internet-Drafts > > database usually indicates that the I-D has been replaced? > > > > The results were a bit confusing because it lists the Status as > > Expired, but the I-D Tracker State as I-D Exists, even though the I-D > > Tracker results in "No matches to your query." > > > > Thanks! See you in a couple of weeks! > > > > Sandy > > > > > On Mar 5, 2009, at 8:22 AM, Orly Nicklass wrote: > > > > > > >HI, > > > > > > > >I review the publication list and noticed that some of the > > > >information is not accurate. The not received draft is in the > > > >repository, I put reference to it. And one is already RFC by now. > > > > > > > >Pls advice how to adjust those states correctly > > > > > > > > > > > >2008-07-21 draft-ietf-pwe3-enet-mib-13.txt PLS see new > > > >draft: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-enet- > > > >mib-14.txt MISSREFREF draft-ietf-pwe3-pw-mib IN-QUEUE > > > >draft-ietf-pwe3-pw-tc-mib NOT-RECEIVED pls see: http:// > > > >www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-tc-mib-15.txtD. > > > >Zelig, Ed., T. Nadeau, Ed."Ethernet Pseudowire (PW) Management > > > >Information Base (MIB)"Bytes: 44473Working Group: Pseudo Wire > > > >Emulation Edge to Edge > > > > > > > > > > > >2008-06-23 draft-ietf-pwe3-pw-mib-14.txtMISSREFREF draft- > > > >ietf-pwe3-pw-tc-mib NOT-RECEIVED pls see: http:// > > > >www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-tc-mib-15.txtT. > > > >Nadeau, Ed., D. Zelig, Ed."Pseudowire (PW) Management Information > > > >Base (MIB)"Bytes: 128939Working Group: Pseudo Wire Emulation Edge > > > >to Edge > > > > > > > > > > > >2008-11-18 draft-ietf-pwe3-pw-atm-mib-06.txtMISSREFREF > > > >draft-ietf-pwe3-pw-tc-mib NOT-RECEIVED pls see: http:// > > > >www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-tc- > > > >mib-15.txt draft-ietf-pwe3-pw-mib IN-QUEUE draft-ietf- > > > >pwe3-pw-mpls-mib IN-QUEUEO. Nicklass, S. Sathappan, M. > > > >Venkatesan, T. Nadeau"Managed Objects for ATM over Packet Switched > > > >Network (PSN)"Bytes: 73158Working Group: Pseudo Wire Emulation Edge > > > >to Edge > > > > > > > >2009-02-09 draft-ietf-pwe3-tdm-mib-11.txtMISSREFREF draft- > > > >vainshtein-pwe3-tdm-control-protocol-extensi NOT-RECEIVED this > > > >RFC by now: http://www.ietf.org/rfc/rfc5287.txt draft-ietf- > > > >pwe3-pw-mib IN-QUEUE draft-ietf-pwe3-pw-tc-mib NOT- > > > >RECEIVED pls see: http://www.ietf.org/internet-drafts/draft-ietf- > > > >pwe3-pw-tc-mib-15.txtO. Nicklass"Managed Objects for TDM over > > > >Packet Switched Network (PSN)"Bytes: 81329Working Group: Pseudo > > > >Wire Emulation Edge to Edge > > > > > > > > > > > >2008-07-21 draft-ietf-pwe3-pw-mpls-mib-14.txtMISSREFREF > > > >draft-ietf-pwe3-pw-tc-mib NOT-RECEIVED pls see: http:// > > > >www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-tc- > > > >mib-15.txt draft-ietf-pwe3-pw-mib IN-QUEUED. Zelig, Ed., T. > > > >Nadeau, Ed."Pseudowire (PW) over MPLS PSN Management Information > > > >Base (MIB)"Bytes: 62692Working Group: Pseudo Wire Emulation Edge to > > > >Edge > > > > > > > > > > > > > > > > > > > >Orly Nicklass, Ph.D > > > >VP R&D, NBU > > > >RADVISION? > > > >Delivering the Visual ExperienceTM > > > >Phone: +97237679444 > > > >Mobile: 0547769444 > > > > > > > > > > > ----- End forwarded message ----- > > > > From wwwrun@core3.amsl.com Thu Mar 5 12:33:17 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n25KVrEM012547 for ; Thu, 5 Mar 2009 12:31:54 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 027693A6BB8; Thu, 5 Mar 2009 12:31:22 -0800 (PST) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #13665 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 05 Mar 2009 12:31:22 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #13665] Resolved: Re: PWE mib -- draft-vainshtein-pwe3-tdm-control-protocol-extensi According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Thu Mar 12 12:51:44 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES, SUBJ_HAS_UNIQ_ID autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n2CJp2sl026936 for ; Thu, 12 Mar 2009 12:51:03 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 50F783A6A73; Thu, 12 Mar 2009 12:50:24 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090312185017.GC7242@isi.edu> References: <49B94385.1060609@secunet.com> <20090312185017.GC7242@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #13888 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 12 Mar 2009 12:50:24 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #13888] AutoReply: Re: [Fwd: New Version Notification - draft-lochter-pkix-brainpool-ecc-03.txt] Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: [Fwd: New Version Notification - draft-lochter-pkix-brainpool-ecc-03.txt]", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #13888]. Please include the string: [rt.amsl.com #13888] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- IESG, Please note that a new version of this document has been submitted. The author notified us that version -03 is now available. Thank you. RFC Editor On Thu, Mar 12, 2009 at 06:16:53PM +0100, Johannes Merkle wrote: > Dear RFC Editors, > > version 03 includes all changes requested by the reviewers (Alfred Hoenes and Gerhard Frey) we agreed on with Bob > Braden. Thus, we think that the draft is ready to be published as an RFC. Please inform us how to proceed. > > Best regards, > Johannes Merkle > > > > > > -------- Original Message -------- > Subject: New Version Notification - draft-lochter-pkix-brainpool-ecc-03.txt > Date: Fri, 6 Mar 2009 16:30:02 -0800 (PST) > From: ID Tracker > To: manfred.lochter@bsi.bund.de, johannes.merkle@secunet.com, > draft-lochter-pkix-brainpool-ecc@tools.ietf.org,tim.polk@nist.gov > > New version (-03) has been submitted for draft-lochter-pkix-brainpool-ecc-03.txt. > http://www.ietf.org/internet-drafts/draft-lochter-pkix-brainpool-ecc-03.txt > > > > IETF Secretariat. From wwwrun@core3.amsl.com Fri Mar 13 09:10:55 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n2DG9jej006562 for ; Fri, 13 Mar 2009 09:09:45 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 1388728C189; Fri, 13 Mar 2009 09:09:05 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090313160825.GD6570@isi.edu> References: <49ba7c46.47c1f10a.082b.ffffe863@mx.google.com> <20090313160825.GD6570@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #13912 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 13 Mar 2009 09:09:06 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #13912] AutoReply: Re: Author info change for three drafts in your queue Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Author info change for three drafts in your queue", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #13912]. Please include the string: [rt.amsl.com #13912] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Hi Tom and IESG Secretariat*, Thanks for providing us with your updated email address. a) We have updated our database and the documents to reflect your new address. However, when the documents reach AUTH48, we expect that you may want to change your street address as well. b*) We are unsure whether there is an IETF author's database. We are including the IETF Secretariat in this thread in the hopes that they can provide you with that information. c) There is no issue with our processing the documents with/without the RFC 5378 copyright at this time. You do not need to resubmit your documents since they have already been approved for publication and are in our queue. During the transition to the RFC 5378 copyright notice and legends, we are updating the text with the new RFC 5378 copyright notice, and including the optional 6.c.iii paragrph by default for I-Ds that were submitted with the pre-RFC-5378 copyright. During AUTH48, you will have the opportunity to tell us whether the optional 6.c.iii is not necessary and can be deleted. Please let us know if you have any questions. Thanks! RFC Editor/sg On Fri, Mar 13, 2009 at 11:30:47AM -0400, Tom Talpey wrote: > I am a co-author of three drafts from the NFSv4 working group > which are in the editor's queue. I am, however, no longer at > NetApp, to which the drafts and probably your database point. > > So, I'd like to: > a) let you know my current best address (above), and > b) ask whether there is some other registry I need to > change - the IETF author's database? > > The drafts in question are: > draft-ietf-nfsv4-nfs-rdma-problem-statement > draft-ietf-nfsv4-rpcrdma > draft-ietf-nfsv4-nfsdirect > > Oh, one other question perhaps. Of the three, only -rpcrdma uses > the new RFC5378 assignment text. Is there any issue with the > other two; should they be updated, or do they proceed as-is? > > The source for these three drafts is available on request. They've > been in the works for a long time, so they are in nroff format. > > Tom. From wwwrun@core3.amsl.com Wed Mar 25 10:52:20 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n2PHp7dS015399 for ; Wed, 25 Mar 2009 10:51:08 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 31C6F3A6D4A; Wed, 25 Mar 2009 10:50:13 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090325175049.GB6740@isi.edu> References: <20090325175049.GB6740@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #14379 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 25 Mar 2009 10:50:14 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #14379] AutoReply: Informational Independent Submission: draft-despres-6rd-02.txt Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Informational Independent Submission: draft-despres-6rd-02.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #14379]. Please include the string: [rt.amsl.com #14379] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- IESG, This document was submitted to the RFC Editor to be published as an Informational Independent Submission: draft-despres-6rd-02.txt Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. IPv6 Rapid Deployment on IPv4 infrastructures (6rd) IPv6 rapid deployment (6rd) builds upon mechanisms of 6to4 (RFC3056) to enable a service provider to rapidly deploy IPv6 unicast service to IPv4 sites to which it provides customer premise equipment. Like 6to4, it utilizes stateless IPv6 in IPv4 encapsulation in order to transit IPv4-only network infrastructure. Unlike 6to4, a 6rd service provider uses an IPv6 prefix of its own in place of the fixed 6to4 prefix. A service provider has used this mechanism for its own IPv6 "rapid deployment": five weeks from first exposure to 6rd principles to more than 1,500,000 residential sites being provided quasi-native IPv6, under the only condition that they activate it. Five week timeout expires on 29 April 2009. (Note that we have included an additional week because of the current IETF.) Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents From wwwrun@core3.amsl.com Wed Mar 25 11:05:00 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n2PI3qKV020428 for ; Wed, 25 Mar 2009 11:03:52 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 50A153A6D56; Wed, 25 Mar 2009 11:02:59 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090325180313.GC6740@isi.edu> References: <20090325180313.GC6740@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #14385 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 25 Mar 2009 11:02:59 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #14385] AutoReply: Informational Independent Submission: draft-leung-mip4-proxy-mode-10.txt Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Informational Independent Submission: draft-leung-mip4-proxy-mode-10.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #14385]. Please include the string: [rt.amsl.com #14385] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- IESG, This document was submitted to the RFC Editor to be published as an Independent Independent Submission: draft-leung-mip4-proxy-mode-10.txt Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. WiMAX Forum/3GPP2 Proxy Mobile IPv4 Mobile IPv4 is a standard mobility protocol that enables IPv4 device to move among networks while maintaining its IP address. The mobile device has the Mobile IPv4 client function to signal its location to the routing anchor, known as the Home Agent. However, there are many IPv4 devices without such capability due to various reasons. This document describes Proxy Mobile IPv4 (PMIPv4), a scheme based on having the Mobile IPv4 client function in a network entity to provide mobility support for an unaltered and mobility-unaware IPv4 device. This document also describes a particular application of PMIPv4 as specified in the WiMAX Forum and another application that is to be adopted in 3GPP2. Five week timeout expires on 29 April 2009. Note that we have included an additional week because of the current IETF. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents From wwwrun@core3.amsl.com Wed Mar 25 11:10:26 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n2PI97C3023071 for ; Wed, 25 Mar 2009 11:09:07 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 1919C3A6B7D; Wed, 25 Mar 2009 11:08:13 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090325180808.GD6740@isi.edu> References: <20090325180313.GC6740@isi.edu> <20090325180808.GD6740@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #14387 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 25 Mar 2009 11:08:14 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #14387] AutoReply: Re: Informational Independent Submission: draft-leung-mip4-proxy-mode-10.txt Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Informational Independent Submission: draft-leung-mip4-proxy-mode-10.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #14387]. Please include the string: [rt.amsl.com #14387] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- IESG, Please disregard the message below. We have previously received your "no problem with publication" message on 15 September 2008. Sorry for the confusion! Thank you. RFC Editor On Wed, Mar 25, 2009 at 11:03:13AM -0700, RFC Editor wrote: > IESG, > > This document was submitted to the RFC Editor to be published as an > Independent Independent Submission: draft-leung-mip4-proxy-mode-10.txt > > Please let us know if this document conflicts with the IETF standards > process or other work being done in the IETF community. > > > WiMAX Forum/3GPP2 Proxy Mobile IPv4 > > Mobile IPv4 is a standard mobility protocol that enables IPv4 > device to move among networks while maintaining its IP address. > The mobile device has the Mobile IPv4 client function to signal its > location to the routing anchor, known as the Home Agent. However, > there are many IPv4 devices without such capability due to various > reasons. This document describes Proxy Mobile IPv4 (PMIPv4), a > scheme based on having the Mobile IPv4 client function in a network > entity to provide mobility support for an unaltered and > mobility-unaware IPv4 device. This document also describes a > particular application of PMIPv4 as specified in the WiMAX Forum > and another application that is to be adopted in 3GPP2. > > Five week timeout expires on 29 April 2009. > Note that we have included an additional week because of the current > IETF. > > Sincerely, > > Sandy Ginoza - USC/ISI > Request for Comments Documents From wwwrun@core3.amsl.com Wed Mar 25 11:15:06 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n2PIEjOM025712 for ; Wed, 25 Mar 2009 11:14:46 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id E370D3A696F; Wed, 25 Mar 2009 11:13:52 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #14385 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 25 Mar 2009 11:13:52 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #14385] Resolved: Informational Independent Submission: draft-leung-mip4-proxy-mode-10.txt According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Thu Mar 26 10:10:38 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n2QH9qEb024714 for ; Thu, 26 Mar 2009 10:09:53 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 6E4DE28C0E4; Thu, 26 Mar 2009 10:08:58 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #14379 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 26 Mar 2009 10:08:58 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #14379] Resolved: Informational Independent Submission: draft-despres-6rd-02.txt According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Thu Apr 2 14:27:11 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n32LQqLj015042 for ; Thu, 2 Apr 2009 14:26:53 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 8CAD73A6A53; Thu, 2 Apr 2009 14:25:50 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #13912 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 02 Apr 2009 14:25:50 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #13912] Resolved: Re: Author info change for three drafts in your queue According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Thu Apr 2 14:27:14 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n32LQkP8015010 for ; Thu, 2 Apr 2009 14:26:47 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id C97A63A67AC; Thu, 2 Apr 2009 14:25:43 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090313160825.GD6570@isi.edu> References: <49ba7c46.47c1f10a.082b.ffffe863@mx.google.com> <20090313160825.GD6570@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #13912 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 02 Apr 2009 14:25:43 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #13912] Re: Author info change for three drafts in your queue Hi Tom (and RFC Editor), Your email address has been updated in our database. Best regards, Cindy On Fri Mar 13 09:09:05 2009, rfc-editor@rfc-editor.org wrote: > Hi Tom and IESG Secretariat*, > > Thanks for providing us with your updated email address. > > a) We have updated our database and the documents to reflect your new > address. However, when the documents reach AUTH48, we expect that you > may want to change your street address as well. > > b*) We are unsure whether there is an IETF author's database. We are > including the IETF Secretariat in this thread in the hopes that they > can provide you with that information. > > c) There is no issue with our processing the documents with/without > the RFC 5378 copyright at this time. You do not need to resubmit your > documents since they have already been approved for publication and > are in our queue. > > During the transition to the RFC 5378 copyright notice and legends, we > are updating the text with the new RFC 5378 copyright notice, and > including the optional 6.c.iii paragrph by default for I-Ds that were > submitted with the pre-RFC-5378 copyright. During AUTH48, you will > have the opportunity to tell us whether the optional 6.c.iii is not > necessary and can be deleted. > > Please let us know if you have any questions. > > Thanks! > > RFC Editor/sg > > > > On Fri, Mar 13, 2009 at 11:30:47AM -0400, Tom Talpey wrote: > > I am a co-author of three drafts from the NFSv4 working group > > which are in the editor's queue. I am, however, no longer at > > NetApp, to which the drafts and probably your database point. > > > > So, I'd like to: > > a) let you know my current best address (above), and > > b) ask whether there is some other registry I need to > > change - the IETF author's database? > > > > The drafts in question are: > > draft-ietf-nfsv4-nfs-rdma-problem-statement > > draft-ietf-nfsv4-rpcrdma > > draft-ietf-nfsv4-nfsdirect > > > > Oh, one other question perhaps. Of the three, only -rpcrdma uses > > the new RFC5378 assignment text. Is there any issue with the > > other two; should they be updated, or do they proceed as-is? > > > > The source for these three drafts is available on request. They've > > been in the works for a long time, so they are in nroff format. > > > > Tom. > From wwwrun@core3.amsl.com Tue Apr 28 09:26:34 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n3SGKaNS006748 for ; Tue, 28 Apr 2009 09:20:37 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id E49FE28C0F6; Tue, 28 Apr 2009 09:19:13 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090428161656.GB1827@isi.edu> References: <20090428161656.GB1827@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #14960 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 28 Apr 2009 09:19:13 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #14960] AutoReply: Informational Independent Submission: draft-templin-isatapv4-01.txt Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Informational Independent Submission: draft-templin-isatapv4-01.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #14960]. Please include the string: [rt.amsl.com #14960] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- IESG, This document was submitted to the RFC Editor to be published as an Informational Independent Submission: draft-templin-isatapv4-01.txt Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Transmission of IPv4 Packets over ISATAP Interfaces The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) specifies a Non-Broadcast, Multiple Access (NBMA) interface type for the transmission of IPv6 packets over IPv4 networks using automatic IPv6-in-IPv4 encapsulation. The original specifications make no provisions for the encapsulation and transmission of IPv4 packets, however. This document specifies a method for transmitting IPv4 packets over ISATAP interfaces. Four week timeout expires on 26 May 2009. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents From wwwrun@core3.amsl.com Tue Apr 28 09:35:23 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n3SGTYNW011957 for ; Tue, 28 Apr 2009 09:29:35 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id C10AE3A6C33; Tue, 28 Apr 2009 09:28:12 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090428162242.GC1827@isi.edu> References: <20090428145552.30C3528C1D8@core3.amsl.com> <20090428162242.GC1827@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #14961 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 28 Apr 2009 09:28:12 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #14961] AutoReply: Re: Protocol Action: 'Mobile IPv6 Support for Dual Stack Hosts and Routers' to Proposed Standard Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Mobile IPv6 Support for Dual Stack Hosts and Routers' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #14961]. Please include the string: [rt.amsl.com #14961] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Tue, Apr 28, 2009 at 07:55:52AM -0700, The IESG wrote: > The IESG has approved the following document: > > - 'Mobile IPv6 Support for Dual Stack Hosts and Routers ' > as a Proposed Standard > > This document is the product of the Mobility EXTensions for IPv6 Working > Group. > > The IESG contact persons are Jari Arkko and Ralph Droms. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-v4traversal-10.txt > > Technical Summary > > The current Mobile IPv6 and NEMO specifications support IPv6 only. > This specification extends those standards to allow the registration > of IPv4 addresses and prefixes, respectively, and the transport of > both IPv4 and IPv6 packets over the tunnel to the home agent. This > specification also allows the Mobile Node to roam over both IPv6 and > IPv4, including the case where Network Address Translation is present > on the path between the mobile node and its home agent. > > Working Group Summary > > This document is a product of the Mobility EXTensions for IPv6 > (MEXT) working group. > > Document Quality > > Pasi Eronen reviewed the specification and his comments regarding > interaction of DSMIPv6 with the IPsec architecture were resolved. > > Personnel > > The Document Shepherd for this document is Julien Laganier > (MEXT WG co-chair). The Responsible Area Director is Jari Arkko > (Internet Area Director). > > RFC Editor Note > > Please add the following paragraph to the end of Section 5.4.4: > > This specification does not support mobile nodes returning home > while using IPv4. That is, the IPv4 support is only defined for > mobile nodes that are in a visited network. From wwwrun@core3.amsl.com Tue Apr 28 09:41:25 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n3SGZSIw015329 for ; Tue, 28 Apr 2009 09:35:29 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id D8D663A703C; Tue, 28 Apr 2009 09:34:05 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #14961 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 28 Apr 2009 09:34:05 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #14961] Resolved: Re: Protocol Action: 'Mobile IPv6 Support for Dual Stack Hosts and Routers' to Proposed Standard According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Tue Apr 28 11:16:36 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on clone.isi.edu X-Spam-Level: X-Spam-Status: No, score=-4.1 required=5.0 tests=ANY_BOUNCE_MESSAGE,AWL, BAYES_00,RCVD_IN_DNSWL_MED,VBOUNCE_MESSAGE autolearn=ham version=3.2.4 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n3SI8Idv005367 for ; Tue, 28 Apr 2009 11:08:19 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 34BD928C282; Tue, 28 Apr 2009 11:06:45 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090428180053.GD1827@isi.edu> References: <20090428180053.GD1827@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #14963 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 28 Apr 2009 11:06:46 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #14963] AutoReply: Informational Independent Submission: draft-brusilovsky-pak-09.txt Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Informational Independent Submission: draft-brusilovsky-pak-09.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #14963]. Please include the string: [rt.amsl.com #14963] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- IESG, This document was submitted to the RFC Editor to be published as an Informational Independent Submission: draft-brusilovsky-pak-09.txt. Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Four week timeout expires on 26 May 2009. Password-Authenticated Diffie-Hellman Exchange (PAK) This document proposes to add mutual authentication, based on human-memorizable password, to the basic unauthenticated Diffie-Hellman key exchange. The proposed algorithm is called Password-authenticated Key exchange (PAK). PAK allows two parties to authenticate themselves while performing the Diffie-Hellman exchange. The protocol is secure against all passive and active attacks. In particular, it does not allow either type of attackers to obtain any information that would enable an off-line dictionary attack on the password. PAK provides Forward Secrecy. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents From wwwrun@core3.amsl.com Tue Apr 28 11:31:06 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n3SIKO26012909 for ; Tue, 28 Apr 2009 11:20:24 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id E40A33A711E; Tue, 28 Apr 2009 11:19:01 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090428181041.GE1827@isi.edu> References: <20090428162054.D881728C0DC@core3.amsl.com> <20090428181041.GE1827@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #14964 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 28 Apr 2009 11:19:01 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #14964] AutoReply: Re: Protocol Action: 'Internet Calendaring and Scheduling Core Object Specification (iCalendar)' to Proposed Standard Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Internet Calendaring and Scheduling Core Object Specification (iCalendar)' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #14964]. Please include the string: [rt.amsl.com #14964] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Tue, Apr 28, 2009 at 09:20:54AM -0700, The IESG wrote: > The IESG has approved the following document: > > - 'Internet Calendaring and Scheduling Core Object Specification > (iCalendar) ' > as a Proposed Standard > > This document is the product of the Calendaring and Scheduling Standards > Simplification Working Group. > > The IESG contact persons are Lisa Dusseault and Alexey Melnikov. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2445bis-10.txt > > Technical Summary > > This document defines the iCalendar data format for representing and > exchanging calendaring and scheduling information such as events, > to-dos, journal entries and free/busy information, independent of any > particular calendar service or protocol. > > Working Group Summary > > The working group proceeded with the work in an orderly fashion, opening > tickets for all the found issues in the original RFC2445, and then > systematically closing them until no known issues remained. > > Document Quality > > There are a number of existing implementations of the original RFC2445 > specification that are likely to upgrade their implementation to the new > specification. > > During the process of developing this document, the CalConnect.org > industry consortium provided various types of vendor feedback and errata > over the original specification. > > The working group took special care to take into account this feedback > as well as the feedback received from a number of other contributors, > some of which are also mentioned in the document's Acknowledgements > section. > > Personnel > > Document Shepherd: Aki Niemi > > Responsible AD: Lisa Dusseault > > The IANA Expert(s) for the registries in this document are Cyrus Daboo > and Bernard Desruisseaux. > > > Note to RFC Editor > > Please ensure that the ABNF is valid, including semi-colons or explicit > spaces in empty lines within rules. > > OLD in section 3.2.19: > > The parameter MUST be specified on properties with a DATE-TIME > value if the DATE-TIME is not either a UTC or a "floating" time. > > NEW: > > The parameter MUST be specified on properties with a DATE-TIME > value if the DATE-TIME is not either a UTC or a "floating" time. > Failure to include and follow VTIMEZONE definitions in iCalendar > objects may lead to inconsistent understanding of the local time at any > given location. From wwwrun@core3.amsl.com Tue Apr 28 12:37:24 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n3SJWjX4021752 for ; Tue, 28 Apr 2009 12:32:45 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id A4E593A6D20; Tue, 28 Apr 2009 12:31:17 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #14964 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 28 Apr 2009 12:31:17 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #14964] Resolved: Re: Protocol Action: 'Internet Calendaring and Scheduling Core Object Specification (iCalendar)' to Proposed Standard According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Tue Apr 28 13:15:40 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n3SKE7gZ012096 for ; Tue, 28 Apr 2009 13:14:08 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 55CEA3A6960; Tue, 28 Apr 2009 13:12:44 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #14963 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 28 Apr 2009 13:12:45 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #14963] Resolved: Informational Independent Submission: draft-brusilovsky-pak-09.txt According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Wed Apr 29 08:36:43 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n3TFYHqj021996 for ; Wed, 29 Apr 2009 08:34:18 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 6B0D63A7144; Wed, 29 Apr 2009 08:32:54 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090429153136.GA11879@isi.edu> References: <20090428200907.7E8E93A6929@core3.amsl.com> <20090429153136.GA11879@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #14993 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 29 Apr 2009 08:32:54 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #14993] AutoReply: Re: Protocol Action: 'BGP IPsec Tunnel Encapsulation Attribute' to Proposed Standard Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'BGP IPsec Tunnel Encapsulation Attribute' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #14993]. Please include the string: [rt.amsl.com #14993] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Tue, Apr 28, 2009 at 01:09:07PM -0700, The IESG wrote: > The IESG has approved the following document: > > - 'BGP IPsec Tunnel Encapsulation Attribute ' > as a Proposed Standard > > This document is the product of the Softwires Working Group. > > The IESG contact persons are Ralph Droms and Jari Arkko. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-softwire-encaps-ipsec-03.txt > > Technical Summary > > The BGP Encapsulation Subsequence Address Family Identifiers (SAFI) > provides a method for the dynamic exchange of encapsulation > information, and the indication of encapsulation protocol types > to be used for different next hops. Currently support for GRE and L2TPv3 > tunnel types are defined. This document defines support for IPsec > tunnel types. > > > Working Group Summary > > The SOFTWIRE WG supports the development and advancement of this > document. > > > Protocol Quality > > This document was thoroughly reviewed by WG chairs and WG members, > including those with expertise in IPv4 to IPv6 transitions and > interworking. > > Dave Ward is the WG chair shepherd. Ralph Droms is the > responsible Area director. From wwwrun@core3.amsl.com Wed Apr 29 08:54:03 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n3TFjtLj028099 for ; Wed, 29 Apr 2009 08:45:56 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id CE97528C2C6; Wed, 29 Apr 2009 08:44:32 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090429153845.GB11879@isi.edu> References: <20090429132440.8529128C1CC@core3.amsl.com> <20090429153845.GB11879@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #14994 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 29 Apr 2009 08:44:32 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #14994] AutoReply: Re: Protocol Action: 'LDP Capabilities' to Proposed Standard Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'LDP Capabilities' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #14994]. Please include the string: [rt.amsl.com #14994] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Wed, Apr 29, 2009 at 06:24:40AM -0700, The IESG wrote: > The IESG has approved the following document: > > - 'LDP Capabilities ' > as a Proposed Standard > > This document is the product of the Multiprotocol Label Switching Working > Group. > > The IESG contact persons are Ross Callon and Adrian Farrel. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-capabilities-04.txt > > Technical Summary > > A number of enhancements to the Label Distribution Protocol (LDP) > have been proposed. Some have been implemented, and some are > advancing toward standardization. It is likely that additional > enhancements will be proposed in the future. At present, LDP has > no mechanism for advertising such enhancements at LDP session > initialization time. There is also no mechanism to enable and > disable enhancements after the session is established. This > document defines a mechanism for advertising LDP enhancements at > session initialization time, as well as a mechanism to enable and > disable enhancements after LDP session establishment. > > Working Group Summary > > This document represents the WG consensus as a whole: the WG as > a whole understands and agrees with it. The document has been > through wg last call with good and constructive comments, it has > also been reviewed by subject-matter experts who are WG members. > No controvery reported (see PROTO writeup by Loa Andersson in > the tracker) > > Document Quality > > There is at least one known implementation. The document has been > well reviewed in the WG and updated based on Gen-Art comments. > > Personnel > > Loa Andersson is the Document Shepherd for this document. Ross > Callon is the Responsible Area Director. > > RFC Editor Note > > The address and corporate affiliation for Bob Thomas should be > double checked. He can be contacted at: bobt727@yahoo.com. From wwwrun@core3.amsl.com Wed Apr 29 09:08:45 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n3TFxgr4005207 for ; Wed, 29 Apr 2009 08:59:43 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 0E1E73A6ECE; Wed, 29 Apr 2009 08:58:19 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #14993 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 29 Apr 2009 08:58:20 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #14993] Resolved: Re: Protocol Action: 'BGP IPsec Tunnel Encapsulation Attribute' to Proposed Standard According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Wed Apr 29 09:12:33 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n3TG0g9L005686 for ; Wed, 29 Apr 2009 09:00:43 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 18C5928C2B5; Wed, 29 Apr 2009 08:59:19 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #14994 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 29 Apr 2009 08:59:20 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #14994] Resolved: Re: Protocol Action: 'LDP Capabilities' to Proposed Standard According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Wed Apr 29 09:18:03 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n3TG1wno006235 for ; Wed, 29 Apr 2009 09:01:58 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 76BBC28C2DE; Wed, 29 Apr 2009 09:00:34 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090429154822.GC11879@isi.edu> References: <20090429154822.GC11879@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #14995 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 29 Apr 2009 09:00:34 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #14995] AutoReply: [zeltsan@alcatel-lucent.com: RE: Informational Independent Submission: draft-brusilovsky-pak-09.txt] Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "[zeltsan@alcatel-lucent.com: RE: Informational Independent Submission: draft-brusilovsky-pak-09.txt]", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #14995]. Please include the string: [rt.amsl.com #14995] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- IESG, Please note that the authors notified us that version 10 is now available. Please review version 10. Thank you. RFC Editor ----- Forwarded message from "Zeltsan, Zachary (Zachary)" ----- Subject: RE: Informational Independent Submission: draft-brusilovsky-pak-09.txt Date: Wed, 29 Apr 2009 09:44:13 -0500 From: "Zeltsan, Zachary \(Zachary\)" To: "RFC Editor" , "IESG" , "iesg-secretary" Cc: "Brusilovsky, Alec \(Alec\)" , "Faynberg, Igor \(Igor\)" , , "Tim Polk" , "Ray Pelletier" , "Alfred HNnes" , "Jim Schaad" Dear RFC Editor, Please note that the latest version of the draft is -10. (http://tools.ietf.org/html/draft-brusilovsky-pak-10) With best regards, Zachary Zeltsan > -----Original Message----- > From: RFC Editor [mailto:rfc-editor@rfc-editor.org] > Sent: Tuesday, April 28, 2009 2:01 PM > To: IESG; iesg-secretary > Cc: RFC Editor; Brusilovsky, Alec (Alec); Faynberg, Igor > (Igor); sarvar@google.com; Zeltsan, Zachary (Zachary) > Subject: Informational Independent Submission: > draft-brusilovsky-pak-09.txt > > IESG, > > This document was submitted to the RFC Editor to be published > as an Informational Independent Submission: > draft-brusilovsky-pak-09.txt. > > Please let us know if this document conflicts with the IETF > standards process or other work being done in the IETF community. > > Four week timeout expires on 26 May 2009. > > > Password-Authenticated Diffie-Hellman Exchange (PAK) > > This document proposes to add mutual authentication, based on > human-memorizable password, to the basic unauthenticated > Diffie-Hellman key exchange. The proposed algorithm is called > Password-authenticated Key exchange (PAK). PAK allows two parties > to authenticate themselves while performing the Diffie-Hellman > exchange. > > The protocol is secure against all passive and active attacks. > In particular, it does not allow either type of attackers to obtain > any information that would enable an off-line dictionary attack on > the password. PAK provides Forward Secrecy. > > Sincerely, > > Sandy Ginoza - USC/ISI > Request for Comments Documents > ----- End forwarded message ----- From wwwrun@core3.amsl.com Fri May 8 11:37:26 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n48IaICE016716 for ; Fri, 8 May 2009 11:36:19 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 68EBB3A6D9D; Fri, 8 May 2009 11:34:49 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090508183521.GC22575@isi.edu> References: <20090508183521.GC22575@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #15133 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 08 May 2009 11:34:49 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #15133] AutoReply: Informational Independent Submission: draft-ford-behave-top-06.txt Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Informational Independent Submission: draft-ford-behave-top-06.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #15133]. Please include the string: [rt.amsl.com #15133] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- IESG, This document was submitted to the RFC Editor to be published as an Informational Independent Submission: draft-ford-behave-top-06.txt. Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Unintended Consequence of two NAT deployments with Overlapping Address Space This document identifies two deployment scenarios that have arisen from the unconventional network topologies formed using Network Address Translator devices (NATs). First, the simplicity of administering networks through the combination of NAT and DHCP has increasingly lead to the deployment of multi-level inter-connected private networks involving overlapping private IP address spaces. Second, the proliferation of private networks in enterprises, hotels and conferences, and the wide spread use of Virtual Private Networks (VPNs) to access enterprise intranet from remote locations has increasingly lead to overlapping private IP address space between remote and corporate networks. The document does not dismiss these unconventional scenarios as invalid, but recognizes them as real and offers recommendations to help ensure these deployments can function without a meltdown. Four week timeout expires on 5 June 2009. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents From wwwrun@core3.amsl.com Fri May 8 16:14:51 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n48NDu31002056 for ; Fri, 8 May 2009 16:13:57 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 361E33A6B78; Fri, 8 May 2009 16:12:27 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #15133 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 08 May 2009 16:12:27 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #15133] Resolved: Informational Independent Submission: draft-ford-behave-top-06.txt According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Thu May 14 15:35:25 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n4EMXJpj013183 for ; Thu, 14 May 2009 15:33:19 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 4271D28C35D; Thu, 14 May 2009 15:31:45 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090514223052.GA3014@isi.edu> References: <39C363776A4E8C4A94691D2BD9D1C9A105F06EF8@XCH-NW-7V2.nw.nos.boeing.com> <4A0C5F6B.1040009@piuha.net> <39C363776A4E8C4A94691D2BD9D1C9A105F06F42@XCH-NW-7V2.nw.nos.boeing.com> <4A0C6843.1060908@piuha.net> <20090514223052.GA3014@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #15235 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 14 May 2009 15:31:45 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #15235] AutoReply: Informational Indepenent Submission: draft-templin-seal-23.txt Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Informational Indepenent Submission: draft-templin-seal-23.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #15235]. Please include the string: [rt.amsl.com #15235] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- IESG, This document was submitted to the RFC Editor to be published as an Informational Independent Submission: draft-templin-seal-23.txt. This document was previously submitted for IESG review for Experimental publication in August 2008. We are resumbitting this document for consideration as an Informational publication for the reasons Jari specifies in the message below. Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Four week timeout expires on 11 May 2009. The Subnetwork Encapsulation and Adaptation Layer (SEAL) For the purpose of this document, subnetworks are defined as virtual topologies that span connected network regions bounded by encapsulating border nodes. These virtual topologies may span multiple IP and/or sub-IP layer forwarding hops, and can introduce failure modes due to packet duplication and/or links with diverse Maximum Transmission Units (MTUs). This document specifies a Subnetwork Encapsulation and Adaptation Layer (SEAL) that accommodates such virtual topologies over diverse underlying link technologies. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents On Thu, May 14, 2009 at 09:51:47PM +0300, Jari Arkko wrote: > All, > > I marked draft-templin-seal as something that we'll deal on the next > Thursday's IESG telechat. This draft has been in the RFC editor process > already, and had passed the IESG's RFC 3932 review some time ago. > > IESG: The draft is being brought back because Fred wants to change the > status from Exp to Inf. I think that is fine, but I think its fair to > ask from the whole IESG. My recommendation will be the same one that we > (or Mark) had for this the last time around. That is, I am in favor of > the publication. > > Fred: You have no extreme hurry with the document update. I said > originally that for the changes you wouldn't even have to bring them > changes back to the IESG. Its just the status change that needs a check. > But it would be good if you can get the new version in, say by Saturday. > If for some reason you find out that you need more time, just let us > know and we can take it off from the agenda. > > RFC Editor: given Fred's request, I have bypassed a bit of process here, > because normally the RFC Editor would come and ask the IESG for these > checks. This was done just to avoid an extra couple weeks of delay if > the document doesn't make to the agenda that goes out in few hours. You > could still send the formal request, or if you like, just record what > the state of the document is. I think we agree that status changes or > significant revision warrants a new check. The former was the case here. > > Jari From wwwrun@core3.amsl.com Thu May 14 16:03:55 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n4EN2veO024789 for ; Thu, 14 May 2009 16:02:58 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 0E73A3A6911; Thu, 14 May 2009 16:01:23 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090514230110.GD3014@isi.edu> References: <20090514230110.GD3014@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #15236 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 14 May 2009 16:01:24 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #15236] AutoReply: Informational Independent Submission: draft-floyd-tcpm-ackcc-05.txt Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Informational Independent Submission: draft-floyd-tcpm-ackcc-05.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #15236]. Please include the string: [rt.amsl.com #15236] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- IESG, This document was submitted to the RFC Editor to be published as an Informational Independent Submission: draft-floyd-tcpm-ackcc-05.txt. Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Adding Acknowledgement Congestion Control to TCP This document describes a possible congestion control mechanism for acknowledgement traffic (ACKs) in TCP. The document specifies an end-to-end acknowledgement congestion control mechanism for TCP that uses participation from both TCP hosts, the TCP data sender and the TCP data receiver. The TCP data sender detects lost or ECN-marked ACK packets, and tells the TCP data receiver the ACK Ratio R to use to respond to the congestion on the reverse path from the data receiver to the data sender. The TCP data receiver sends roughly one ACK packet for every R data packets received. This mechanism is based on the acknowledgement congestion control in DCCP's CCID 2. This acknowledgement congestion control mechanism is being specified for further evaluation by the network community. Four week timeout expires on 11 June 2009. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents From wwwrun@core3.amsl.com Fri May 15 08:59:43 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n4FFwsuC003672 for ; Fri, 15 May 2009 08:58:54 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 07BB13A6DB2; Fri, 15 May 2009 08:57:03 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #15235 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 15 May 2009 08:57:04 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #15235] Resolved: Informational Indepenent Submission: draft-templin-seal-23.txt According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Fri May 15 09:16:58 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n4FGG22j011750 for ; Fri, 15 May 2009 09:16:02 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id F365728C221; Fri, 15 May 2009 09:14:27 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #15236 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 15 May 2009 09:14:27 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #15236] Resolved: Informational Independent Submission: draft-floyd-tcpm-ackcc-05.txt According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From wwwrun@core3.amsl.com Tue May 26 15:05:01 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES, SUBJ_HAS_UNIQ_ID autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n4QM4VWg006907 for ; Tue, 26 May 2009 15:04:31 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id CB4013A6C9E; Tue, 26 May 2009 15:02:48 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #13888 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 26 May 2009 15:02:48 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #13888] Resolved: Re: [Fwd: New Version Notification - draft-lochter-pkix-brainpool-ecc-03.txt] We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Mon Jun 8 09:51:01 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n58GnuxY000027 for ; Mon, 8 Jun 2009 09:50:00 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id D9DF73A6B3F; Mon, 8 Jun 2009 09:49:50 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090608164937.GD28803@isi.edu> References: <20090608150729.87E373A6DE0@core3.amsl.com> <20090608164937.GD28803@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #15716 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Mon, 08 Jun 2009 09:49:50 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #15716] AutoReply: Re: Document Action: 'Lemonade Notifications Architecture' to Informational RFC Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'Lemonade Notifications Architecture' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #15716]. Please include the string: [rt.amsl.com #15716] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Mon, Jun 08, 2009 at 08:07:29AM -0700, The IESG wrote: > The IESG has approved the following document: > > - 'Lemonade Notifications Architecture ' > as an Informational RFC > > This document is the product of the Enhancements to Internet email to > Support Diverse Service Environments Working Group. > > The IESG contact persons are Alexey Melnikov and Lisa Dusseault. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-lemonade-notifications-10.txt > > Technical Summary > > This document discusses how to provide notification and filtering > mechanisms to mail stores to meet Lemonade goals. > > This document also discusses the use of server to server > notifications, and how server to server notifications fit into an > architecture which provides server to client notifications. > > Working Group Summary > > Nothing out of the ordinary happened in the WG to note. > > Document Quality > > As an Informative document, no issues with protocols or > implementations. > > RFC Editor Notes > > Please change the Absract to read: > OLD: > This document discusses how to provide notification and filtering > mechanisms to mail stores to meet Lemonade goals. > > NEW: > This document discusses how to provide notification and filtering > mechanisms to mail stores to meet the goals of the Lemonade > (Enhancements to Internet email to Support Diverse Service > Environments) Working Group. > > In Section 1, 1st paragraph: > OLD: > The lemonade work [LEMONADE-PROFILE] identified a need to provide > ^ > notification and filtering mechanisms for use with IMAP [IMAP]. > > NEW: > The Lemonade work [LEMONADE-PROFILE] identified a need to provide > ^ > notification and filtering mechanisms for use with IMAP [IMAP]. From wwwrun@core3.amsl.com Mon Jun 8 09:58:29 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n58GvmcO003421 for ; Mon, 8 Jun 2009 09:57:49 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 839083A6A14; Mon, 8 Jun 2009 09:57:42 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090608165145.GE28803@isi.edu> References: <20090608163305.1F8A53A6DB9@core3.amsl.com> <20090608165145.GE28803@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #15717 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Mon, 08 Jun 2009 09:57:42 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #15717] AutoReply: Re: Protocol Action: 'GSS-API Extension for Storing Delegated Credentials' to Proposed Standard Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'GSS-API Extension for Storing Delegated Credentials' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #15717]. Please include the string: [rt.amsl.com #15717] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Mon, Jun 08, 2009 at 09:33:05AM -0700, The IESG wrote: > The IESG has approved the following document: > > - 'GSS-API Extension for Storing Delegated Credentials ' > as a Proposed Standard > > This document is the product of the Kitten (GSS-API Next Generation) > Working Group. > > The IESG contact persons are Tim Polk and Pasi Eronen. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-store-cred-04.txt > > Technical Summary > > This document defines a new function for the GSS-API which allows > applications to store delegated (and other) credentials in the > implicit GSS-API credential store. This is needed for GSS-API > applications to use delegated credentials as they would use other > credentials. > > Working Group Summary > > This docment is a product of the kitten working group. The working > group process was uneventful. > > Document Quality > > There is at least 1 existing implementation of the feature and other > implementors are interested. > > Personnel > > Alexey Melnikov is the document shepherd for > this document. Tim Polk is the responsible AD. > > RFC Editor Note > > Please make the following changes: > > (1) In Section 3: > > OLD: > > o default_cred BOOLEAN -- if TRUE make the stored credential > available as the default credential (for acquisition with > GSS_C_NO_NAME as the desired name or for use as > GSS_C_NO_CREDENTIAL) > > > NEW: > > o default_cred BOOLEAN -- advisory input; if TRUE make the stored > credential available as the default credential (for acquisition > with GSS_C_NO_NAME as the desired name or for use as > GSS_C_NO_CREDENTIAL) > > (2) In Section 3: > > OLD: > > Finally, if the current credential store has no default credential > (that is, no credential that could be acquired for GSS_C_NO_NAME) or > if the default_cred input argument is TRUE, and the input credential > can be successfully stored, then the input credential will be > available for acquisition with GSS_C_NO_NAME as the desired name > input to GSS_Acquire_cred() or GSS_Add_cred() as well as for use as > GSS_C_NO_CREDENTIAL for the cred_handle inputs to GSS_Inquire_cred(), > GSS_Inquire_cred_by_mech(), GSS_Init_sec_context() and > GSS_Accept_sec_context(). > > > NEW: > > In the GSS-API the default credential can be used by using > GSS_C_NO_CREDENTIAL or a CREDENTIAL handle acquired by calling > GSS_Acquire_cred() or GSS_Add_cred() with the desired_name input set > to GSS_C_NO_NAME. > > If the default_cred input argument is TRUE, and the input credential > can be successfully stored, then the input credential SHOULD be > stored as the default credential (see above). > > If the current credential store has no default credential (see above) > then the implementation MAY make the stored credentials available as > the default credential regardless of the value of the default_cred > input argument. From wwwrun@core3.amsl.com Mon Jun 8 10:07:22 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n58H6Lbb007337 for ; Mon, 8 Jun 2009 10:06:22 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 798033A6B64; Mon, 8 Jun 2009 10:06:15 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090608170308.GF28803@isi.edu> References: <20090608163756.EA3C83A6D02@core3.amsl.com> <20090608170308.GF28803@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #15718 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Mon, 08 Jun 2009 10:06:15 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #15718] AutoReply: Re: Protocol Action: 'Extended Generic Security Service Mechanism Inquiry APIs' to Proposed Standard Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Extended Generic Security Service Mechanism Inquiry APIs' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #15718]. Please include the string: [rt.amsl.com #15718] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Mon, Jun 08, 2009 at 09:37:56AM -0700, The IESG wrote: > The IESG has approved the following document: > > - 'Extended Generic Security Service Mechanism Inquiry APIs ' > as a Proposed Standard > > This document is the product of the Kitten (GSS-API Next Generation) > Working Group. > > The IESG contact persons are Tim Polk and Pasi Eronen. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-kitten-extended-mech-inquiry-06.txt > > Technical Summary > > This document introduces new application programming interfaces > (APIs) to the Generic Security Services API (GSS-API) for extended > mechanism attribute inquiry. > > This document provides new functionality to obtain specific GSS-API > mechanism attributes. It defines new GSS-API functions that allow > retrieval and display of said attributes. These interfaces are primarily > intended to reduce instances of hardcoding of mechanism identifiers > in GSS applications. > > Working Group Summary > > The WG process was not controversial. > > Document Quality > > There are no implementors of these interfaces that we know of. However, > there should be significant demand once these interfaces become > standard, as a number of applications have hard-coded around limitations > of the current GSS-API. Enabling better programming practices is desired. > > Personnel > > Shawn M. Emery is the document shepherd for this > document. Tim Polk is the responsible AD. > > RFC Editor Note > > Please make the following six changes: > > (1) Section 3.4.2, title: > > s/3.4.2. GSS_Indicate_mechs_by_attr()/3.4.2. > GSS_Indicate_mechs_by_attrs()/ > > (2) Section 3.4.3, last sentence: > > s/GSS_Inquire_mech_attrs_for_mech()/GSS_Inquire_attrs_for_mech() > > (3) Section 3.4.6, third sentence: > > s/typdefs/typedefs/ > > (4) Section 3.4.6, Figure 2 > > OLD: > OM_uint32 gss_inquire_mechs_for_attrs( > OM_uint32 *minor_status, > gss_const_OID_set desired_mech_attrs, > gss_const_OID_set except_mech_attrs, > gss_const_OID_set critical_mech_attrs, > gss_OID_set *mechs); > NEW: > OM_uint32 gss_indicate_mechs_by_attrs( > OM_uint32 *minor_status, > gss_const_OID_set desired_mech_attrs, > gss_const_OID_set except_mech_attrs, > gss_const_OID_set critical_mech_attrs, > gss_OID_set *mechs); > > (5) Section 5, first sentence: > > s/namsepace/namespace/ > > (6) Section 5, first sentence: > > s/IESG Protocol Action/IETF Consensus/ From wwwrun@core3.amsl.com Mon Jun 8 11:08:57 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n58I8SMk028096 for ; Mon, 8 Jun 2009 11:08:28 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 539A03A6DCA; Mon, 8 Jun 2009 11:08:22 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #15716 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Mon, 08 Jun 2009 11:08:22 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #15716] Resolved: Re: Document Action: 'Lemonade Notifications Architecture' to Informational RFC We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Mon Jun 8 11:09:27 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n58I8v6j028242 for ; Mon, 8 Jun 2009 11:08:58 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id F3BC53A6DD9; Mon, 8 Jun 2009 11:08:51 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #15717 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Mon, 08 Jun 2009 11:08:51 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #15717] Resolved: Re: Protocol Action: 'GSS-API Extension for Storing Delegated Credentials' to Proposed Standard We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Mon Jun 8 11:10:36 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n58I9kNp028470 for ; Mon, 8 Jun 2009 11:09:47 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 8A8573A69E3; Mon, 8 Jun 2009 11:09:40 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #15718 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Mon, 08 Jun 2009 11:09:40 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #15718] Resolved: Re: Protocol Action: 'Extended Generic Security Service Mechanism Inquiry APIs' to Proposed Standard We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Mon Jun 8 17:04:29 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n59031vX023431 for ; Mon, 8 Jun 2009 17:03:02 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 4188028C161; Mon, 8 Jun 2009 17:02:54 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090609000205.GM28803@isi.edu> References: <20090608172139.83AFD3A6878@core3.amsl.com> <20090609000205.GM28803@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #15732 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Mon, 08 Jun 2009 17:02:55 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #15732] AutoReply: Re: Document Action: 'Implications of 'retransmission-allowed' for SIP Location Conveyance' to Informational RFC Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'Implications of 'retransmission-allowed' for SIP Location Conveyance' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #15732]. Please include the string: [rt.amsl.com #15732] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Mon, Jun 08, 2009 at 10:21:39AM -0700, The IESG wrote: > The IESG has approved the following document: > > - 'Implications of 'retransmission-allowed' for SIP Location Conveyance ' > as an Informational RFC > > This document is the product of the Geographic Location/Privacy Working > Group. > > The IESG contact persons are Cullen Jennings and Robert Sparks. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-sip-lo-retransmission-02.txt > > Technical Summary > > This document explores an ambiguity in the interpretation of the > element of the Presence Information Data Format > for Location Objects (PIDF-LO) in cases where PIDF-LO is conveyed by the > Session Initiation Protocol (SIP). It provides recommendations for how > the SIP location conveyance mechanism should adapt to this ambiguity. > > Working Group Summary > > This document was produced in order to express the consensus of the > GEOPRIV working group on a privacy issue raised by location conveyance > in the SIP protocol. There is thus strong consensus within GEOPRIV > around the core privacy recommendations in the document. > > Document Quality > > The document has been reviewed by key participants from the GEOPRIV, > SIP, and privacy community, and its recommendations have been > implemented in draft-ietf-sip-location-conveyance-13. > > Personnel > > Document Shepherd is Richard Barnes. > > RFC Editor Note > > > At the end of first paragraph of the Abstract > OLD: > these ambiguities > NEW: > this ambiguity From wwwrun@core3.amsl.com Mon Jun 8 17:21:18 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n590I2fg029204 for ; Mon, 8 Jun 2009 17:18:03 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id C57503A6C08; Mon, 8 Jun 2009 17:17:56 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090609001654.GN28803@isi.edu> References: <20090608225919.93D5E3A6C6A@core3.amsl.com> <20090609001654.GN28803@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #15733 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Mon, 08 Jun 2009 17:17:56 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #15733] AutoReply: Re: Document Action: 'Internet Mail Architecture' to Informational RFC Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'Internet Mail Architecture' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #15733]. Please include the string: [rt.amsl.com #15733] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Mon, Jun 08, 2009 at 03:59:19PM -0700, The IESG wrote: > The IESG has approved the following document: > > - 'Internet Mail Architecture ' > as an Informational RFC > > This document has been reviewed in the IETF but is not the product of an > IETF Working Group. > > The IESG contact person is Alexey Melnikov. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-crocker-email-arch-14.txt > > Technical Summary > > Public discussion of the Internet Mail service often lacks > common terminology and a common frame of reference for these > components and their activities. Having a common reference > model and terminology makes a basic difference when talking > about problems with the service, changes in policy, or > enhancement to the service's functionality. This document > offers an enhanced Internet Mail architecture that targets > description of the existing service, in order to facilitate > clearer and more efficient technical, operations and policy > discussions about email. > > Working Group Summary > > This document was discussed within the mail community on the > mailing lists dedicated to SMTP and the Mail Format. Some of the > terms came about as a compromise after long discussions, but > rough consensus was achieved on all points. Members of the > working groups dealing with IMAP and LEMONADE were aware of this > effort, but it was not an appropriate topic for those working > groups to place on their charters. There is no other current > working group dealing with the mail system in general. > > Document Quality > > This document does not create a protocol specification. > > The acknowledgments indicate that Graham Klyne, Pete Resnick > and Steve Atkins provided thoughtful insight on the framework > and details of the original drafts. A number of other people > have provided additional reviews and insights. > > Personnel > > Who is the Document Shepherd for this document? Tony Hansen > Who is the Responsible Area Director? Chris Newman and Alexey Melnikov > have reviewed this document for IESG. > > > RFC Editor Note > > Please replace [RFC3685] with [RFC5235]. > > In Section 3.4.1, 2nd paragraph, 1st sentence: > OLD: > Message-ID: is be globally unique. > ^^ > NEW: > Message-ID: is globally unique. > ^ From wwwrun@core3.amsl.com Tue Jun 9 06:50:51 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n59DnQIU029500 for ; Tue, 9 Jun 2009 06:49:27 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 27C693A6912; Tue, 9 Jun 2009 06:49:19 -0700 (PDT) From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #15732 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 09 Jun 2009 06:49:20 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #15732] Resolved: Re: Document Action: 'Implications of 'retransmission-allowed' for SIP Location Conveyance' to Informational RFC We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Tue Jun 9 06:51:44 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n59DoSMc029929 for ; Tue, 9 Jun 2009 06:50:29 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id D29803A6856; Tue, 9 Jun 2009 06:50:18 -0700 (PDT) From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #15733 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 09 Jun 2009 06:50:18 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #15733] Resolved: Re: Document Action: 'Internet Mail Architecture' to Informational RFC We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Mon Jun 29 17:09:24 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n5U08kDR008139 for ; Mon, 29 Jun 2009 17:08:47 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 0B28328C181; Mon, 29 Jun 2009 17:08:24 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090630000706.GD13898@isi.edu> References: <9abf48a60906271119h59ed4472o7a0ac7d0b80b8394@mail.gmail.com> <20090630000706.GD13898@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #16291 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Mon, 29 Jun 2009 17:08:25 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #16291] AutoReply: Re: What happened to draft-irtf-asrg-dnsbl ? Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: What happened to draft-irtf-asrg-dnsbl ?", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #16291]. Please include the string: [rt.amsl.com #16291] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have received an inquiry about the state of , and I'm hoping you can help me sort this out. The I-D tracker lists the state as "Approved-announcement sent." However, we do not believe we have received a document action for this I-D. The comment log lists the additional action after "Approved-announcement sent": State Changes to IESG Evaluation from Approved-announcement to be sent by system The above entry has the same entry date as "Approved-anouncement sent." Could you please check the state of this document and (re)send the document action as necessary? Please let me know if you have questions. Thanks! Sandy On Sat, Jun 27, 2009 at 02:19:52PM -0400, Barry Leiba wrote: > Hi, Aaron, RFC Editor, > What ever happened to > https://datatracker.ietf.org/idtracker/draft-irtf-asrg-dnsbl/ > after all the discussion? The tracker says the state went to > "approved, announcement sent" in December, but I don't see it in the > RFC list nor in the RFC Editor queue. What did I miss? > > Barry > -- > Barry Leiba (barryleiba@computer.org) > http://internetmessagingtechnology.org/ From wwwrun@core3.amsl.com Tue Jun 30 06:38:48 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n5UDbhvB015978 for ; Tue, 30 Jun 2009 06:37:44 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 49F533A6B16; Tue, 30 Jun 2009 06:37:19 -0700 (PDT) From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090630000706.GD13898@isi.edu> References: <9abf48a60906271119h59ed4472o7a0ac7d0b80b8394@mail.gmail.com> <20090630000706.GD13898@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #16291 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 30 Jun 2009 06:37:19 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #16291] Re: What happened to draft-irtf-asrg-dnsbl ? Hi Sandy, As this is an IRTF document, that question is for them. The IESG discussed this document at the end of 2008, and it was approved as the IESG had "No Problem" with the IRTF publishing it. The message went back to the IRTF (via the IRSG) with a copy to the IETF-Announce list. As far as what happens next, I am assuming the IRTF takes it from there with the decision to publish it or not, and when, in the process, to get the RFC Editor involved. The Secretariat procedures for IRTF documents was changed last year, so we do not send the messages to the RFC Editor, and it was requested that we not cc the RFC Editor on the messages, either. You may view the message here: http://www.ietf.org/mail-archive/web/ietf-announce/current/msg05534.html I would think this person should query Aaron Falk as the IRTF Chair to find out what is going on with the document (or perhaps the asrg research group). Thanks! Amy On Mon Jun 29 17:08:24 2009, rfc-editor@rfc-editor.org wrote: > Greetings, > > We have received an inquiry about the state of > , and I'm hoping you can help me sort this out. > The I-D tracker lists the state as "Approved-announcement sent." > However, we do not believe we have received a document action for this > I-D. The comment log lists the additional action after > "Approved-announcement sent": > > State Changes to IESG Evaluation from Approved-announcement to be > sent by system > > The above entry has the same entry date as "Approved-anouncement > sent." Could you please check the state of this document and (re)send > the document action as necessary? > > Please let me know if you have questions. > > Thanks! > Sandy > > On Sat, Jun 27, 2009 at 02:19:52PM -0400, Barry Leiba wrote: > > Hi, Aaron, RFC Editor, > > What ever happened to > > https://datatracker.ietf.org/idtracker/draft-irtf-asrg-dnsbl/ > > after all the discussion? The tracker says the state went to > > "approved, announcement sent" in December, but I don't see it in the > > RFC list nor in the RFC Editor queue. What did I miss? > > > > Barry > > -- > > Barry Leiba (barryleiba@computer.org) > > http://internetmessagingtechnology.org/ > From wwwrun@core3.amsl.com Tue Jun 30 09:15:30 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n5UGEmKm017537 for ; Tue, 30 Jun 2009 09:14:49 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id D3EC03A6BB2; Tue, 30 Jun 2009 09:14:26 -0700 (PDT) Subject: Re: [rt.amsl.com #16291] Re: What happened to draft-irtf-asrg-dnsbl ? From: "RFC Editor via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090630161302.GA25609@isi.edu> References: <9abf48a60906271119h59ed4472o7a0ac7d0b80b8394@mail.gmail.com> <20090630000706.GD13898@isi.edu> <20090630161302.GA25609@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #16291 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 30 Jun 2009 09:14:26 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Hi Amy! Thanks, I will check with Aaron. I thought that when the I-D tracker indicated "approved-announcement sent" that it meant that a message had been sent to the RFC Editor. I didn't realize that that state is used to signify that an approved message was sent to other bodies. Good to know that we didn't have a disconnect!! Thanks for the info; it's a big help! As a side note, it would be great if the I-D tracker and the announcement messages could be updated to treat the IRTF documents as their own stream (as defined by RFC 4844), as they are not Independent submissions and they are no longer treated as such. Maybe this is something the secretariat could look into after is published as an RFC (it's in our queue waiting for 3932bis to be approved), as the following text could then point to the published RFC: The process for such documents is described at http://www.rfc-editor.org/indsubs.html. Thanks for your help and your consideration! Sandy On Tue, Jun 30, 2009 at 06:37:19AM -0700, Amy Vezza via RT wrote: > Hi Sandy, > > As this is an IRTF document, that question is for them. The IESG > discussed this document at the end of 2008, and it was approved as the > IESG had "No Problem" with the IRTF publishing it. The message went > back to the IRTF (via the IRSG) with a copy to the IETF-Announce list. > As far as what happens next, I am assuming the IRTF takes it from there > with the decision to publish it or not, and when, in the process, to get > the RFC Editor involved. > > The Secretariat procedures for IRTF documents was changed last year, so > we do not send the messages to the RFC Editor, and it was requested that > we not cc the RFC Editor on the messages, either. You may view the > message here: > > http://www.ietf.org/mail-archive/web/ietf-announce/current/msg05534.html > > I would think this person should query Aaron Falk as the IRTF Chair to > find out what is going on with the document (or perhaps the asrg > research group). > > Thanks! > > Amy > > On Mon Jun 29 17:08:24 2009, rfc-editor@rfc-editor.org wrote: > > Greetings, > > > > We have received an inquiry about the state of > > , and I'm hoping you can help me sort this out. > > The I-D tracker lists the state as "Approved-announcement sent." > > However, we do not believe we have received a document action for this > > I-D. The comment log lists the additional action after > > "Approved-announcement sent": > > > > State Changes to IESG Evaluation from Approved-announcement to be > > sent by system > > > > The above entry has the same entry date as "Approved-anouncement > > sent." Could you please check the state of this document and (re)send > > the document action as necessary? > > > > Please let me know if you have questions. > > > > Thanks! > > Sandy > > > > On Sat, Jun 27, 2009 at 02:19:52PM -0400, Barry Leiba wrote: > > > Hi, Aaron, RFC Editor, > > > What ever happened to > > > https://datatracker.ietf.org/idtracker/draft-irtf-asrg-dnsbl/ > > > after all the discussion? The tracker says the state went to > > > "approved, announcement sent" in December, but I don't see it in the > > > RFC list nor in the RFC Editor queue. What did I miss? > > > > > > Barry > > > -- > > > Barry Leiba (barryleiba@computer.org) > > > http://internetmessagingtechnology.org/ > > > > From wwwrun@core3.amsl.com Tue Jun 30 15:44:53 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n5UMhbQA005641 for ; Tue, 30 Jun 2009 15:43:37 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 4AA6D3A68CF; Tue, 30 Jun 2009 15:43:14 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090630224225.GC25609@isi.edu> References: <20090629162841.9EF0B28C27B@core3.amsl.com> <20090630224225.GC25609@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #16354 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 30 Jun 2009 15:43:15 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #16354] AutoReply: Re: Protocol Action: 'Softwire Security Analysis and Requirements' to Proposed Standard Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Softwire Security Analysis and Requirements' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #16354]. Please include the string: [rt.amsl.com #16354] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Mon, Jun 29, 2009 at 09:28:41AM -0700, The IESG wrote: > The IESG has approved the following document: > > - 'Softwire Security Analysis and Requirements ' > as a Proposed Standard > > This document is the product of the Softwires Working Group. > > The IESG contact persons are Ralph Droms and Jari Arkko. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-softwire-security-requirements-09.txt > > Technical Summary > > This document describes the security guidelines for the softwire > "Hubs and Spokes" and "Mesh" solutions. Together with the discussion of > the softwire deployment scenarios, the vulnerability to the security > attacks is analyzed to provide the security protection mechanism such as > authentication, integrity and confidentiality to the softwire > control and data packets. > > Working Group Summary > > The SOFTWIRE WG supports the development and advancement of this > document. > > Protocol Quality > > This document was thoroughly reviewed by WG chairs and WG members, > including those with expertise in security, IPv4 to IPv6 > transitions and interworking. From wwwrun@core3.amsl.com Wed Jul 1 08:11:18 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n61FABOK024787 for ; Wed, 1 Jul 2009 08:10:11 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id A08103A683F; Wed, 1 Jul 2009 08:09:48 -0700 (PDT) From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #16354 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 01 Jul 2009 08:09:48 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #16354] Resolved: Re: Protocol Action: 'Softwire Security Analysis and Requirements' to Proposed Standard We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Tue Jul 7 15:12:51 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n67MCMBM023574 for ; Tue, 7 Jul 2009 15:12:23 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 076A928C2C5; Tue, 7 Jul 2009 15:11:55 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090707221054.GI21503@isi.edu> References: <20090707215624.272B63A6EAD@core3.amsl.com> <20090707221054.GI21503@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #16547 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 07 Jul 2009 15:11:56 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #16547] AutoReply: Re: draft-ietf-smime-3278bis Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: draft-ietf-smime-3278bis", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #16547]. Please include the string: [rt.amsl.com #16547] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings IESG Secretary, Thanks for bringing this to our attention! It turns out that we must have missed it somehow! The document is being added now! Thanks, RFC Editor On Tue, Jul 07, 2009 at 02:56:24PM -0700, IESG Secretary wrote: > Hello! > > We wanted to check in with you folks about the state of > draft-ietf-smime-3278bis. The IESG approved this document, and the > announcement was sent out on June 8, 2009, but the document has not > appeared in the RFC Editor queue yet. > > For reference, the text of the approval announcement is copied below. > > Best regards, > IESG Secretary > > ----- > From: The IESG > To: IETF-Announce > Reply-to: iesg-secretary@ietf.org > Subject: Document Action: 'Use of Elliptic Curve Cryptography (ECC) > Algorithms in Cryptographic Message Syntax (CMS)' to Informational RFC > > The IESG has approved the following document: > > - 'Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic > Message Syntax (CMS) ' > as an Informational RFC > > This document is the product of the S/MIME Mail Security Working Group. > > The IESG contact persons are Tim Polk and Pasi Eronen. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-smime-3278bis-09.txt > > Technical Summary > > This document describes how to use Elliptic Curve Cryptography > (ECC) public-key algorithms in the Cryptographic Message Syntax (CMS). > The ECC algorithms support the creation of digital signatures and the > exchange of keys to encrypt or authenticate content. The definition of > the algorithm processing is based on the NIST FIPS 186-3 for digital > signatures, NIST SP800-56A and SEC1 for key agreement, RFC 3370 and > RFC 3565 for key wrap and content encryption, NIST FIPS 180-3 for > message digest, SEC1 for key derivation, and RFC 2104 and RFC 4231 > for message authentication code standards. This document > obsoletes RFC 3278. > > Working Group Summary > > This document was discussed on the S/MIME WG mailing list. The discussion > was primarily about document quality and consistency. > > Document Quality > > Implementations of SignedData with ECDSA and EnvelopedData with ECDH > have been available for some time from multiple vendors. Implementation > of the "new" algorithms (i.e., using SHA-2 and AES algorithms) is expected > > shortly, now that the relevant NIST documents (e.g., FIPS 186-3) have been > > finalized. > > Personnel > > Russ Housley is the document PROTO Shepherd. Tim Polk is the responsible > Security Area AD. From wwwrun@core3.amsl.com Tue Jul 7 15:59:37 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n67MwVUq009612 for ; Tue, 7 Jul 2009 15:58:31 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id E05D93A6E3D; Tue, 7 Jul 2009 15:58:03 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #16547 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 07 Jul 2009 15:58:03 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #16547] Resolved: Re: draft-ietf-smime-3278bis We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Fri Aug 14 09:34:09 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n7EGXkd5001420 for ; Fri, 14 Aug 2009 09:33:47 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 0FB6828C17A; Fri, 14 Aug 2009 09:33:41 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090814163311.GB17212@isi.edu> References: <20090508183521.GC22575@isi.edu> <20090814163311.GB17212@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #17979 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 14 Aug 2009 09:33:42 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #17979] AutoReply: Re: Informational Independent Submission: draft-ford-behave-top-07.txt Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Informational Independent Submission: draft-ford-behave-top-07.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #17979]. Please include the string: [rt.amsl.com #17979] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- IESG, draft-ford-behave-top-06 was submitted for a RFC 3932 review on 8 May 2009. Please note that the authors have submitted -07 is now available at http://www.rfc-editor.org/internet-drafts/draft-ford-behave-top-07.txt. The authors have made updates in respone to comments from Ralph and and Cullen. Please review the new version and let us know the results of your RFC 3932 review. Thank you. Sandy On Fri, May 08, 2009 at 11:35:22AM -0700, RFC Editor wrote: > IESG, > > This document was submitted to the RFC Editor to be published as an > Informational Independent Submission: draft-ford-behave-top-06.txt. > > Please let us know if this document conflicts with the IETF standards > process or other work being done in the IETF community. > > > Unintended Consequence of two NAT deployments with > Overlapping Address Space > > This document identifies two deployment scenarios that have arisen > from the unconventional network topologies formed using Network > Address Translator devices (NATs). First, the simplicity of > administering networks through the combination of NAT and DHCP has > increasingly lead to the deployment of multi-level inter-connected > private networks involving overlapping private IP address spaces. > Second, the proliferation of private networks in enterprises, > hotels and conferences, and the wide spread use of Virtual Private > Networks (VPNs) to access enterprise intranet from remote locations > has increasingly lead to overlapping private IP address space > between remote and corporate networks. The document does not > dismiss these unconventional scenarios as invalid, but recognizes > them as real and offers recommendations to help ensure these > deployments can function without a meltdown. > > > Four week timeout expires on 5 June 2009. > > > Sincerely, > > Sandy Ginoza - USC/ISI > Request for Comments Documents From wwwrun@core3.amsl.com Tue Aug 25 12:14:00 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n7PJDQZR023194 for ; Tue, 25 Aug 2009 12:13:27 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 76F1A3A6AFB; Tue, 25 Aug 2009 12:13:18 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090825191245.GC25850@isi.edu> References: <20090825191245.GC25850@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #18282 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 25 Aug 2009 12:13:19 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #18282] AutoReply: New RFCs online Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "New RFCs online", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #18282]. Please include the string: [rt.amsl.com #18282] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Hi All, Just a heads up that we have recently put RFCs 11, 109, 110, and 199 online. Russ (awhile back) had asked that we notify you when we're putting old documents online because a manual update may be necessary on the IETF site. Please let us know if you have any questions! Thanks! Sandy From wwwrun@core3.amsl.com Wed Aug 26 08:59:09 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n7QFwbAv007508 for ; Wed, 26 Aug 2009 08:58:38 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 85EBA3A70AC; Wed, 26 Aug 2009 08:57:36 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #18282 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 26 Aug 2009 08:57:36 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #18282] Resolved: New RFCs online We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Fri Aug 28 13:45:55 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n7SKjC8c012401 for ; Fri, 28 Aug 2009 13:45:13 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 892A228C2E9; Fri, 28 Aug 2009 13:45:04 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090828204439.42FA7311525@bosco.isi.edu> References: <20090828204439.42FA7311525@bosco.isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #18355 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 28 Aug 2009 13:45:04 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #18355] AutoReply: Re: Regarding draft-iana-rfc3330bis Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Regarding draft-iana-rfc3330bis", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #18355]. Please include the string: [rt.amsl.com #18355] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, Thank you for letting us know. These 3 documents will be published simultaneously. They are listed as a cluster: http://www.rfc-editor.org/cluster_info.php?cid=C46 RFC Editor/ah On Aug 28, 2009, at 1:57 PM, IESG Secretary wrote: > draft-iana-rfc3330bis-11.txt contains references to these two I-Ds: > > [I-D.iana-ipv4-examples] > Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks > Reserved for Documentation", draft-iana-ipv4-examples-01 > (work in progress), June 2009. > > [I-D.iana-special-ipv4-registry] > Huston, G., Cotton, M., and L. Vegoda, "IANA IPv4 Special > Purpose Address Registry", > draft-iana-special-ipv4-registry-01 (work in progress), > February 2009. > > Please publish all three of these documents as RFCs at the same time. From wwwrun@core3.amsl.com Tue Sep 1 16:05:40 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n81N4c1L024631 for ; Tue, 1 Sep 2009 16:04:39 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 183A03A6E0A; Tue, 1 Sep 2009 16:04:23 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090901230409.GD13142@isi.edu> References: <20090805140150.40D463A6BF9@core3.amsl.com> <20090901230409.GD13142@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #18420 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 01 Sep 2009 16:04:24 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #18420] AutoReply: Re: Protocol Action: 'Multiple Care-of Addresses Registration' to Proposed Standard Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Multiple Care-of Addresses Registration' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #18420]. Please include the string: [rt.amsl.com #18420] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Wed, Aug 05, 2009 at 07:01:50AM -0700, The IESG wrote: > The IESG has approved the following document: > > - 'Multiple Care-of Addresses Registration ' > as a Proposed Standard > > > This document is the product of the Mobility EXTensions for IPv6 Working Group. > > The IESG contact persons are Jari Arkko and Ralph Droms. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-14.txt > > Technical Summary > > According to the current Mobile IPv6 specification, a mobile node may > have several care-of addresses, but only one, called the primary > care-of address, that can be registered with its home agent and the > correspondent nodes. However, for matters of cost, bandwidth, delay, > etc, it is useful for the mobile node to get Internet access through > multiple accesses simultaneously, in which case the mobile node would > be configured with multiple active IPv6 care-of addresses. This > document proposes extensions to the Mobile IPv6 protocol to register > and use multiple care-of addresses. The extensions proposed in this > document can be used by Mobile Routers using the NEMO (Network > Mobility) Basic Support protocol as well. > > Working Group Summary > > This is a product of the former MONAMI6 WG, now part of MEXT WG. > > Document Quality > > There are 3 implementations of the protocol: An implementation > for MIPL (LINUX), more information: > http://www.nautilus6.org/implementation/index.php > http://software.nautilus6.org/MCoA/ > One implementation for BSD called SHISA which is part of WIDE > and is being maintained. Another implementation KDDI R&D. > > Interoperability between KDDI and SHISA in 2005. > http://www.ietf.org/proceedings/05nov/slides/monami6-8.pdf > > This feature is a must for the automotive industry > standardization effort made at ISO. > > There were many reviewers of the document, but especial > in depth reviews were provided by George Tsirtsis, Chan-Wah > Ng and Benjamin Lim. > > No MIB review nor media type reviews were needed. > > Personnel > > The Document Shepherd is Marcelo Bagnulo, and the AD is Jari > Arkko. From wwwrun@core3.amsl.com Tue Sep 1 16:15:06 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n81NEapK028419 for ; Tue, 1 Sep 2009 16:14:37 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 88EEE3A6F40; Tue, 1 Sep 2009 16:14:21 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090901230458.GF13142@isi.edu> References: <20090831154530.B51E028C2E2@core3.amsl.com> <20090901230458.GF13142@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #18426 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 01 Sep 2009 16:14:21 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #18426] AutoReply: Re: Protocol Action: 'Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages' to Proposed Standard Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #18426]. Please include the string: [rt.amsl.com #18426] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Mon, Aug 31, 2009 at 08:45:30AM -0700, The IESG wrote: > The IESG has approved the following document: > > - 'Mapping Simple Network Management Protocol (SNMP) Notifications to > SYSLOG Messages ' > as a Proposed Standard > > > This document is the product of the Operations and Management Area Working Group. > > The IESG contact persons are Dan Romascanu and Ron Bonica. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-opsawg-syslog-snmp-05.txt > > Technical Summary > > This memo defines a mapping from Simple Network Management Protocol > (SNMP) notifications to SYSLOG messages. > > Working Group Summary > > There was consensus in the working group to publish this document. > > Document Quality > > SYSLOG and SNMP are widely implemented and deployed. The document was > reviewed in the Working Group and by the MIB DOctors. > > Personnel > > Scott Bradner is the Document Shepherd. Dan Romascanu is the > Responsible Area Director. From wwwrun@core3.amsl.com Tue Sep 1 16:15:10 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n81NEZIg028416 for ; Tue, 1 Sep 2009 16:14:36 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 225AB3A6E9A; Tue, 1 Sep 2009 16:14:21 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090901230446.GE13142@isi.edu> References: <20090831153935.4252628C30F@core3.amsl.com> <20090901230446.GE13142@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #18427 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 01 Sep 2009 16:14:22 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #18427] AutoReply: Re: Protocol Action: 'Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications' to Proposed Standard Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #18427]. Please include the string: [rt.amsl.com #18427] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Mon, Aug 31, 2009 at 08:39:35AM -0700, The IESG wrote: > The IESG has approved the following document: > > - 'Definitions of Managed Objects for Mapping SYSLOG Messages to Simple > Network Management Protocol (SNMP) Notifications ' > as a Proposed Standard > > > This document is the product of the Operations and Management Area Working Group. > > The IESG contact persons are Dan Romascanu and Ron Bonica. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-opsawg-syslog-msg-mib-06.txt > > Technical Summary > > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet community. > In particular, it defines a mapping of SYSLOG messages to Simple > Network Management Protocol (SNMP) notifications. > > Working Group Summary > > There was consensus in the working group to publish these documents. > > Document Quality > > SNMP and SYSLOG are widely used and deployed. The document was > reviewed in the Working Group and by MIB DOctors. > > Personnel > > Scott Bradner is the Document Shepherd. Dan Romascanu is the > Responsible Area Director. From wwwrun@core3.amsl.com Tue Sep 1 16:15:12 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n81NEZs6028397 for ; Tue, 1 Sep 2009 16:14:35 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 409F93A6CB2; Tue, 1 Sep 2009 16:14:19 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090901230543.GI13142@isi.edu> References: <20090831173337.2E41F28C209@core3.amsl.com> <20090901230543.GI13142@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #18422 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 01 Sep 2009 16:14:20 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #18422] AutoReply: Re: Protocol Action: 'Extended MKCOL for WebDAV' to Proposed Standard Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Extended MKCOL for WebDAV' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #18422]. Please include the string: [rt.amsl.com #18422] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Mon, Aug 31, 2009 at 10:33:37AM -0700, The IESG wrote: > The IESG has approved the following document: > > - 'Extended MKCOL for WebDAV ' > as a Proposed Standard > > > This document is the product of the vCard and CardDAV Working Group. > > The IESG contact persons are Alexey Melnikov and Lisa Dusseault. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-vcarddav-webdav-mkcol-06.txt > > Technical Summary > This specification extends the Web Distributed Authoring and > Versioning (WebDAV) MKCOL method to allow collections of > arbitrary resourcetype to be created and to allow properties > to be set at the same time. It avoids minting new MK* methods > (such as MKCALENDAR) for each new type of collection. > > Working Group Summary > Process was smooth; the only early disagreement was about the > scope of this document (whether it should apply to > non-collection resources as well, and whether it should also > setting ACLs). In the end, the WG converged on the minimal > functionality needed to resolve the issue. > > Document Quality > This protocol extension defined in this document is used > by the VCARDDAV protocol (another deliverable of the Working > Group), for which several vendors have announced support > (for instance, Apple, and Viagenie). > > Personnel > The Document Shepherd for this document was Julian Reschke, > and the responsible Area Director is Alexey Melnikov. From wwwrun@core3.amsl.com Tue Sep 1 16:15:16 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n81NEZIe028416 for ; Tue, 1 Sep 2009 16:14:36 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 012883A6E9A; Tue, 1 Sep 2009 16:14:20 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090901230525.GH13142@isi.edu> References: <20090831173220.B53D93A6E4E@core3.amsl.com> <20090901230525.GH13142@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #18424 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 01 Sep 2009 16:14:20 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #18424] AutoReply: Re: Protocol Action: 'Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer' to Proposed Standard Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #18424]. Please include the string: [rt.amsl.com #18424] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Mon, Aug 31, 2009 at 10:32:20AM -0700, The IESG wrote: > The IESG has approved the following document: > > - 'Elliptic-Curve Algorithm Integration in the Secure Shell Transport > Layer ' > as a Proposed Standard > > This document has been reviewed in the IETF but is not the product of an > IETF Working Group. > > The IESG contact person is Tim Polk. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-green-secsh-ecc-09.txt > > Technical Summary > > This document describes algorithms based on Elliptic Curve > Cryptography (ECC) for use within the Secure Shell (SSH) transport > protocol. In particular, it specifies: Elliptic Curve Diffie-Hellman > (ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key > agreement and Elliptic Curve Digital Signature Algorithm (ECDSA) for > use in the SSH Transport Layer protocol. > > Working Group Summary > > This document is the result an individual submission by members of > the community interested in seeing support for use of ECC algorithms > in the SSH protocol. While there is no active working group behind > this work, it was extensively reviewed and discussed on the ietf-ssh > mailing list, which was the home of the Secure Shell Working Group > before that group concluded and still counts many of the participants > of that working group among its members. > > Document Quality > > While there are no existing implementations of this protocol, there > has been indication of interest from SSH implementors. > > Personnel > > The document shepherd for this document is Jeffrey Hutzelman > The responsible Area Director is Tim Polk. > > RFC Editor Note > > Section 12.1 > > Please remove the URL from the reference [FIPS-180-3]. > > Section 12.2 > > Please remove the URLs from references [NIST-800-57] and [NIST-CURVES]. From wwwrun@core3.amsl.com Tue Sep 1 16:15:20 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n81NEZmf028407 for ; Tue, 1 Sep 2009 16:14:36 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 822273A6CE6; Tue, 1 Sep 2009 16:14:20 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090901230554.GJ13142@isi.edu> References: <20090831173534.E233B28C2AC@core3.amsl.com> <20090901230554.GJ13142@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #18423 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 01 Sep 2009 16:14:20 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #18423] AutoReply: Re: Document Action: 'Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks' to Informational RFC Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #18423]. Please include the string: [rt.amsl.com #18423] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Mon, Aug 31, 2009 at 10:35:34AM -0700, The IESG wrote: > The IESG has approved the following document: > > - 'Network Mobility Route Optimization Requirements for Operational Use > in Aeronautics and Space Exploration Mobile Networks ' > as an Informational RFC > > > This document is the product of the Mobility EXTensions for IPv6 Working Group. > > The IESG contact persons are Jari Arkko and Ralph Droms. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mext-aero-reqs-04.txt > > Technical Summary > > This document describes the requirements and desired properties of > Network Mobility (NEMO) Route Optimization techniques for use in > global networked communications systems for aeronautics and space > exploration. > > Working Group Summary > > This is product of the MEXT WG. > > Document Quality > > Substantial input to these requirements was given by aeronautical > communications experts outside the IETF, including members of the > International Civil Aviation Orgnanization (ICAO) and other > aeronautical communications standards bodies. > > Personnel > > The Document Shepherd is Marcelo Braun, and the responsible > Area Director is Jari Arkko. > > RFC Editor Note > > Please change the following: > > OLD: > (e.g. the Gatelink system) > NEW: > (e.g. local networks available while on a gate) > > OLD: > (currently on the surface when connected to a wired Gatelink system) > NEW: > (currently on the surface when connected to a wired link at a gate) > > OLD: > (link technologies and acronyms are briefly defined in Appendix A. > NEW: > (link technologies and acronyms are briefly defined in Appendix A). > > OLD: > rouge > NEW > rogue From wwwrun@core3.amsl.com Tue Sep 1 16:15:23 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n81NEYsh028396 for ; Tue, 1 Sep 2009 16:14:35 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id C217E3A6B4C; Tue, 1 Sep 2009 16:14:19 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090901230609.GK13142@isi.edu> References: <20090901162302.1BEB43A6CB6@core3.amsl.com> <20090901230609.GK13142@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #18421 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 01 Sep 2009 16:14:19 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #18421] AutoReply: Re: Protocol Action: 'Layered Coding Transport (LCT) Building Block' to Proposed Standard Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Layered Coding Transport (LCT) Building Block' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #18421]. Please include the string: [rt.amsl.com #18421] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Tue, Sep 01, 2009 at 09:23:02AM -0700, The IESG wrote: > The IESG has approved the following document: > > - 'Layered Coding Transport (LCT) Building Block ' > as a Proposed Standard > > > This document is the product of the Reliable Multicast Transport Working Group. > > The IESG contact persons are Magnus Westerlund and Lars Eggert. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-lct-revised-11.txt > > Technical Summary > > This document is an RMT Building Block that specifies protocol headers > and procedures useful for building a reliable multicast transport > protocol that can employ packet-level forward error correction (FEC) > coding to enable massively- scalable, reliable, unidirectional network > data transport without requiring receiver feedback. Layered Coding > Transport is specifically designed to support protocols using IP > multicast, but also provides support to protocols that use unicast. > Layered Coding Transport is compatible with congestion control that > provides multiple rate delivery to receivers. > > Working Group Summary > > There is consensus in the WG to publish this documents. > > Document Quality > > The document is of high quality and has been subject to extensive > review in its Internet Draft and Experimental RFC forms. The > revised draft represents a small number of changes from the original > Experimental RFC 3451. > > Open source implementations of the LCT protocol are available and > considerable experience in using this protocol has been accumulated. > The protocol has been adopted by the Digital Video Broadcasting (DVB) > industry consortium for content delivery. > > The content of this document was already reviewed and approved for > publication as experimental RFC 3451. This document contains minor > technical modifications. > > Personnel > > Brian Adamson is the Document Shepherd. > Magnus Westerlund is the Responsible Area Director. From wwwrun@core3.amsl.com Tue Sep 1 16:15:26 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n81NEa2E028418 for ; Tue, 1 Sep 2009 16:14:36 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 6626C3A6CB2; Tue, 1 Sep 2009 16:14:20 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090901230512.GG13142@isi.edu> References: <20090831172431.725CB28C417@core3.amsl.com> <20090901230512.GG13142@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #18425 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 01 Sep 2009 16:14:21 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #18425] AutoReply: Re: Protocol Action: 'Alarms in SYSLOG' to Proposed Standard Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Alarms in SYSLOG' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #18425]. Please include the string: [rt.amsl.com #18425] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Mon, Aug 31, 2009 at 10:24:31AM -0700, The IESG wrote: > The IESG has approved the following document: > > - 'Alarms in SYSLOG ' > as a Proposed Standard > > > This document is the product of the Operations and Management Area Working Group. > > The IESG contact persons are Dan Romascanu and Ron Bonica. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-opsawg-syslog-alarm-02.txt > > Technical Summary > > This document describes how to send alarm information in syslog. It > includes the mapping of ITU perceived severities onto syslog message > fields and a number of alarm-specific SD-PARAM definitions from X.733 > and the IETF Alarm MIB. > > Working Group Summary > > The document was revised based on WG feedback & the result meets > the issues that were raised. > > Document Quality > > SYSLOG is widely implemented and deployed, and the ITU severities are > > used by a number of protocols and alarm models including the IETF > Alarm MIB. > > Personnel > > Scott Bradner is the Document Shepherd for this document. Dan > Romascanu is the Responsible Area Director. > > RFC Editor Note > > Please insert the following edits in the published version: > > 1. In section 1, > > Old:Alarm related terminology is defined in [RFC3877]. > > > New:Alarm related terminology is defined in [RFC3877]. > > SD-ID, SD-PARM and other syslog related terms are defined in [RFC5424] > > > 2. In section 3 > > Old: the SD-PARARMS are mandatory. > > New: the SD-PARAMS are mandatory. > > > > 3. In section 3.6 > > Old: [RFC1738] and its updates. In the case of an SNMP resource, the > > New: [RFC3986] and its updates. In the case of an SNMP resource, the > > > > 4. In section 4 > > Old: In this example, extended from [Syslog], the VERSION is 1 and the > New: In this example, extended from [RFC5424], the VERSION is 1 and the > > OLD: 'APP-NAME is "su"' > NEW: 'APP-NAME is "evntslog"' > > OLD: 'exampleSDID@0' > NEW: 'exampleSDID@32473' > > OLD: 'resourceURI =' > NEW: 'resourceURI=' > > 5. In section 6 > > Old: IANA is requested to register the SD-IDs > > New: IANA is requested to register the syslog Structured Data ID Values > > 6. In section 8.1 > > Old: [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, > "Uniform > Resource Locators (URL)", RFC 1738, December 1994. > > New: [RFC3986] Berners-Lee, T., Fielding, R., and Masinter, L., > "Uniform Resource Identifier (URI): Generic Syntax", RFC RFC3986, January > 2005. > > 7. In Section 3.1: > > OLD: If the "alarm" SD-ID is supported, the "resource" SD-PARAM MUST be > supported. > > NEW: If the "alarm" SD-ID is included, the "resource" SD-PARAM MUST be > included. > > 8. In Section 3.2: > > OLD: If the "alarm" SD-ID is supported, the "probableCause" SD-PARAM MUST > > > be supported. > > NEW: If the "alarm" SD-ID is included, the "probableCause" SD-PARAM MUST > be included. > > 9. In Section 3.3: > > OLD: If the "alarm" SD-ID is supported, the "perceivedSeverity" SD-PARAM > MUST be supported. > > NEW: If the "alarm" SD-ID is included, the "perceivedSeverity" SD-PARAM > MUST be included. > > 10. In Section 3.4: > > OLD: If the "alarm" SD-ID is supported, the "eventType" SD-PARAM SHOULD > be supported. > > NEW: If the "alarm" SD-ID is included, the "eventType" SD-PARAM SHOULD be > included. > > 11. In Section 3.5: > > OLD: If the "alarm" SD-ID is supported, the "trendIndication" SD-PARAM > SHOULD be supported. > > NEW: If the "alarm" SD-ID is included, the "trendIndication" SD-PARAM > SHOULD be included. > > 12. In Section 3.6: > > OLD: If the "alarm" SD-ID is supported, the "resourceURI" SD-PARAM SHOULD > > > be supported. > > NEW: If the "alarm" SD-ID is included, the "resourceURI" SD-PARAM SHOULD > be included. From wwwrun@core3.amsl.com Wed Sep 2 07:30:42 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n82ETkVL010834 for ; Wed, 2 Sep 2009 07:29:47 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id D4CCC28C804; Wed, 2 Sep 2009 07:29:19 -0700 (PDT) From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #18420 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 02 Sep 2009 07:29:19 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #18420] Resolved: Re: Protocol Action: 'Multiple Care-of Addresses Registration' to Proposed Standard We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Wed Sep 2 07:31:27 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n82EUe86011168 for ; Wed, 2 Sep 2009 07:30:40 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id BC7143A68C4; Wed, 2 Sep 2009 07:30:23 -0700 (PDT) From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #18423 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 02 Sep 2009 07:30:23 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #18423] Resolved: Re: Document Action: 'Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks' to Informational RFC We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Wed Sep 2 07:32:25 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n82EVVps011460 for ; Wed, 2 Sep 2009 07:31:32 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 8D5DE3A68C4; Wed, 2 Sep 2009 07:31:15 -0700 (PDT) From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #18427 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 02 Sep 2009 07:31:15 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #18427] Resolved: Re: Protocol Action: 'Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications' to Proposed Standard We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Wed Sep 2 07:32:47 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n82EW8wU011633 for ; Wed, 2 Sep 2009 07:32:08 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id C879D3A690E; Wed, 2 Sep 2009 07:31:51 -0700 (PDT) From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #18424 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 02 Sep 2009 07:31:51 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #18424] Resolved: Re: Protocol Action: 'Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer' to Proposed Standard We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Wed Sep 2 07:33:52 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n82EXBVf012023 for ; Wed, 2 Sep 2009 07:33:12 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 301853A69E9; Wed, 2 Sep 2009 07:32:55 -0700 (PDT) From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #18425 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 02 Sep 2009 07:32:55 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #18425] Resolved: Re: Protocol Action: 'Alarms in SYSLOG' to Proposed Standard We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Wed Sep 2 07:34:36 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n82EXkEM012241 for ; Wed, 2 Sep 2009 07:33:47 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 3E50E3A690E; Wed, 2 Sep 2009 07:33:30 -0700 (PDT) From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #18421 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 02 Sep 2009 07:33:30 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #18421] Resolved: Re: Protocol Action: 'Layered Coding Transport (LCT) Building Block' to Proposed Standard We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Wed Sep 2 07:34:40 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n82EYQpP012805 for ; Wed, 2 Sep 2009 07:34:26 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id B80823A6915; Wed, 2 Sep 2009 07:34:09 -0700 (PDT) From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #18426 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 02 Sep 2009 07:34:09 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #18426] Resolved: Re: Protocol Action: 'Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages' to Proposed Standard We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Wed Sep 2 07:37:03 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n82EaFo4013581 for ; Wed, 2 Sep 2009 07:36:16 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 4D51B3A68C4; Wed, 2 Sep 2009 07:35:59 -0700 (PDT) From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #18422 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 02 Sep 2009 07:35:59 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #18422] Resolved: Re: Protocol Action: 'Extended MKCOL for WebDAV' to Proposed Standard We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Thu Sep 3 11:14:35 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n83IDHbS003224 for ; Thu, 3 Sep 2009 11:13:18 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id BAFF33A682A; Thu, 3 Sep 2009 11:12:58 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090903181047.GB13105@isi.edu> References: <20090902143820.9D8B23A6A44@core3.amsl.com> <20090903181047.GB13105@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #18469 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 03 Sep 2009 11:12:58 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #18469] AutoReply: Re: Protocol Action: 'IP Performance Metrics (IPPM) for spatial and multicast' to Proposed Standard Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'IP Performance Metrics (IPPM) for spatial and multicast' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #18469]. Please include the string: [rt.amsl.com #18469] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Wed, Sep 02, 2009 at 07:38:20AM -0700, The IESG wrote: > The IESG has approved the following document: > > - 'IP Performance Metrics (IPPM) for spatial and multicast ' > as a Proposed Standard > > > This document is the product of the IP Performance Metrics Working Group. > > The IESG contact persons are Lars Eggert and Magnus Westerlund. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ippm-multimetrics-12.txt > > Technical Summary > > The IETF has standardized IP Performance Metrics (IPPM) for measuring > end-to-end performance between two points. This memo defines two new > categories of metrics that extend the coverage to multiple > measurement points. It defines spatial metrics for measuring the > performance of segments of a source to destination path, and metrics > for measuring the performance between a source and many destinations > in multiparty communications (e.g., a multicast tree). > > Working Group Summary > > The working group input has improved this document through its > revisions, and the document itself has been uncontroversial. > > Document Quality > > No known implementations claim to implement this metric. > However, other implementers in the group have read the draft. > > Personnel > > The document shepherd is Matt Zekauskas (matt@internet2.edu). > Lars Eggert (lars.eggert@nokia.com) reviewed it for the IESG. From wwwrun@core3.amsl.com Thu Sep 3 11:22:41 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n83ILvWJ006903 for ; Thu, 3 Sep 2009 11:21:57 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 1DE773A6814; Thu, 3 Sep 2009 11:21:34 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090903181121.GE13105@isi.edu> References: <20090903175818.867E93A67D1@core3.amsl.com> <20090903181121.GE13105@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #18470 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 03 Sep 2009 11:21:35 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #18470] AutoReply: Re: Protocol Action: 'Four-octet AS Specific BGP Extended Community' to Proposed Standard Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Four-octet AS Specific BGP Extended Community' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #18470]. Please include the string: [rt.amsl.com #18470] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Thu, Sep 03, 2009 at 10:58:18AM -0700, The IESG wrote: > The IESG has approved the following document: > > - 'Four-octet AS Specific BGP Extended Community ' > as a Proposed Standard > > > This document is the product of the Layer 3 Virtual Private Networks Working Group. > > The IESG contact persons are Ross Callon and Adrian Farrel. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-as4octet-ext-community-03.txt > > Technical Summary > > This document defines a new type of a BGP extended community - four- > octet AS specific extended community. This allows the BGP extended > community to carry a 4 octet autonomous system numbers. > > Working Group Summary > > No controvery reported (see PROTO writeup by Danny McPherson in > the I.D. Tracker). This was last called in both the L3VPN and IDR > working groups. > > Document Quality > > The existing capability using 2 octet AS numbers is implemented > and widely deployed. This is a very straightforward extension to > support 4 octet AS numbers. > > Personnel > > Danny McPherson is the Document Shepherd for this document. Ross > Callon is the Responsible Area Director. > > RFC Editor Note > > Please change the abstract to be: > > ABSTRACT > > This document defines a new type of a BGP extended community which > carries a four-octet autonomous system (AS) number. > > Please update the last sentence of the Introduction as follows: > > OLD > > carry a four octets autonomous system number > > NEW > > carry a four octet autonomous system number > > Please replace section 5 (security considerations) with the > following: > > 5. Security Considerations > > This document does not add new security issues. All the security > considerations for BGP Extended Communities apply here. At the time > that this document was written there were significant efforts > underway to improve the security properties of BGP. For examples of > documents that have been produced up to this time of publication, > see [RFC4593] and [SIDR]. > > There is a potential serious issue if a malformed malformed > optional transitive attribute is received. This issue > and the steps to avoid it are discussed in [OPT_TRANS]. > > And add the following references to section 7 (non-normative > references): > > [OPT_TRANS] Scudder, Chen, "Error Handling for Optional > Transitive BGP Attributes", work in progress, > draft-ietf-idr-optional-transitive, April 2009. > > [RFC4593] Barbir, Murphy, Yang, "Generic Threats to Routing > Protocols", RFC4593, October 2006. > > [SIDR] Lepinski, Kent, "An Infrastructure to Support Secure > Internet Routing", work in progress, > draft-ietf-sidr-arch-08.txt, July, 2009. From wwwrun@core3.amsl.com Thu Sep 3 11:22:58 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n83IMMRc006985 for ; Thu, 3 Sep 2009 11:22:24 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 7D05E3A6818; Thu, 3 Sep 2009 11:22:03 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090903181032.GA13105@isi.edu> References: <20090902143657.36BB928C79E@core3.amsl.com> <20090903181032.GA13105@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #18472 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 03 Sep 2009 11:22:03 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #18472] AutoReply: Re: Protocol Action: 'Metering and marking behaviour of PCN-nodes' to Proposed Standard Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Metering and marking behaviour of PCN-nodes' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #18472]. Please include the string: [rt.amsl.com #18472] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Wed, Sep 02, 2009 at 07:36:57AM -0700, The IESG wrote: > The IESG has approved the following document: > > - 'Metering and marking behaviour of PCN-nodes ' > as a Proposed Standard > > > This document is the product of the Congestion and Pre-Congestion Notification Working Group. > > The IESG contact persons are Lars Eggert and Magnus Westerlund. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pcn-marking-behaviour-05.txt > > Technical Summary > > This document specifies two packet metering and marking > behaviours of PCN nodes. These metering and marking > behaviours are implemented in PCN interior nodes to signal > the onset of pre-congestion to PCN boundary nodes. > Threshold-metering and -marking marks all PCN-packets if > the PCN traffic rate is greater than a configured rate > ("PCN-threshold-rate"). Excess-metering and -marking marks > a proportion of PCN-packets, such that the amount marked > equals the traffic rate in excess of a configured rate > ("PCN-excess-rate"). The level of PCN marking allows PCN > boundary nodes to determine the extent of pre-congestion on > ingress-egress paths, which is used to make PCN traffic > admission or termination decisions. > > Working Group Summary > > The document was subject to thorough review by the PCN working > group, and strong consensus for publication was reached. > > Personnel > > The document shepherd was Steven Blake (slblake@petri-meat.com). > Lars Eggert (lars.eggert@nokia.com) reviewed the document for > the IESG. From wwwrun@core3.amsl.com Thu Sep 3 11:23:00 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n83IMMuB006984 for ; Thu, 3 Sep 2009 11:22:23 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 6795C3A6827; Thu, 3 Sep 2009 11:22:03 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090903181107.GD13105@isi.edu> References: <20090903163904.B226C3A6CF6@core3.amsl.com> <20090903181107.GD13105@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #18471 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 03 Sep 2009 11:22:03 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #18471] AutoReply: Re: Protocol Action: 'Locating IEEE 802.21 Mobility Servers using DNS' to Proposed Standard Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Locating IEEE 802.21 Mobility Servers using DNS' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #18471]. Please include the string: [rt.amsl.com #18471] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Thu, Sep 03, 2009 at 09:39:04AM -0700, The IESG wrote: > The IESG has approved the following document: > > - 'Locating IEEE 802.21 Mobility Servers using DNS ' > as a Proposed Standard > > > This document is the product of the Mobility for IP: Performance, Signaling and Handoff Optimization Working Group. > > The IESG contact persons are Jari Arkko and Ralph Droms. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mipshop-mos-dns-discovery-07.txt > > Technical Summary > > This document defines application service tags that allow service > location without relying on rigid domain naming conventions, and DNS > procedures for discovering servers which provide Mobility Services. > Mobility Services are used to assist an MN in handover preparation > (network discovery) and handover decision (network selection). The > services addressed by this document are the Media Independent > Handover Services defined in [1]. > > Working Group Summary > > This is a part of the 802.21 transport functionality, a > chartered work item of the MIPSHOP WG. > > Significant questions were raised in AD review about the > draft. Discussion with DNSDIR members eventually resolved > most of these concerns, and after some modification the > draft is moving forward. > > Document Quality > > Jari Arkko has reviewed this specification for the IESG. > Several DNSDIR reviews have been obtained. > > Personnel > > Vijay Devarapalli is the Document Shepherd. The responsible > Area Director is Jari Arkko. > > RFC Editor Note > > Please change this in the IANA considerations section: > OLD: > New entries to the table that specify additional transport protocols > for the existing Service Fields may be registered by IANA on a First > Come First Served' basis [RFC5226]. > NEW: > New entries to the table that specify additional transport protocols > for the existing Service Fields may similarly be registered by > IANA through Standards Action [RFC5226]. > > Also, please add to the IANA considerations section: > NEW: > IANA is also requested to register MIHIS, MIHES, MIHCS as service > names in the Protocol and Service Name registry. > > And add to the end of the Security Considerations section: > NEW: > Where inputs to the procedure described in this document > are fed via DHCP, DHCP vulnerabilities can also cause > issues. For instance, the inability to authenticate > DHCP discovery results may lead to the mobility service > results also being incorrect, even if the DNS process was > secured. From wwwrun@core3.amsl.com Thu Sep 3 11:23:24 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n83INCax007220 for ; Thu, 3 Sep 2009 11:23:13 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 348CF3A6831; Thu, 3 Sep 2009 11:22:52 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090903181057.GC13105@isi.edu> References: <20090902143956.B76203A6BA7@core3.amsl.com> <20090903181057.GC13105@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #18473 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 03 Sep 2009 11:22:53 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #18473] AutoReply: Re: Protocol Action: 'Signaling LDP Label Advertisement Completion' to Proposed Standard Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Signaling LDP Label Advertisement Completion' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #18473]. Please include the string: [rt.amsl.com #18473] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Wed, Sep 02, 2009 at 07:39:56AM -0700, The IESG wrote: > The IESG has approved the following document: > > - 'Signaling LDP Label Advertisement Completion ' > as a Proposed Standard > > > This document is the product of the Multiprotocol Label Switching Working Group. > > The IESG contact persons are Adrian Farrel and Ross Callon. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-end-of-lib-04.txt > > Technical Summary > > There are situations following LDP session establishment where it > would be useful for a Label Distribution Protocol (LDP) speaker to > know when its peer has advertised all of its labels. For example, > when an LDP speaker is using LDP-IGP synchronization procedures, it > would be useful for the speaker to know when its peer has completed > advertisement of its IP label bindings. > > Similarly, after an LDP session is re-established when LDP Graceful > Restart is in effect, it would be helpful for each peer to signal the > other after it has advertised all its label bindings. > > The LDP specification (RFC 5036) provides no mechanism for an LDP > speaker to notify a peer when it has completed its initial label > advertisements to that peer. > > This document specifies use of a Notification message with the "End- > of-LIB" Status Code for an LDP speaker to signal completion of its > label advertisements following session establishment. > > RFC 5036 implicitly assumes that new Status Codes will be defined > over the course of time. However, it does not explicitly define the > behavior of an LDP speaker which does not understand the Status Code > in a Notification message. To avoid backward compatibility issues > this document specifies use of the LDP capability mechanism at > session establishment time for informing a peer that an LDP speaker > is capable of handling a Notification message that carries an > unrecognized Status Code. > > Working Group Summary > > Nothing of note. > > Document Quality > There are no implementations that we know of. We have polled the > WG list but received no responses > > Personnel > > Loa Andersson (loa@pi.nu) is the Document Shepherd. > Adrian Farrel (adrian.farrel@huawei.com) is the Responsible Area > Director. From wwwrun@core3.amsl.com Thu Sep 3 13:01:42 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n83K0rV0009986 for ; Thu, 3 Sep 2009 13:00:54 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 6DC693A6842; Thu, 3 Sep 2009 13:00:34 -0700 (PDT) From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #18469 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 03 Sep 2009 13:00:34 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #18469] Resolved: Re: Protocol Action: 'IP Performance Metrics (IPPM) for spatial and multicast' to Proposed Standard We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Thu Sep 3 13:02:14 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n83K1TeY010186 for ; Thu, 3 Sep 2009 13:01:30 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 35A523A689A; Thu, 3 Sep 2009 13:01:10 -0700 (PDT) From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #18470 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 03 Sep 2009 13:01:10 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #18470] Resolved: Re: Protocol Action: 'Four-octet AS Specific BGP Extended Community' to Proposed Standard We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Thu Sep 3 13:02:57 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n83K2QFA010508 for ; Thu, 3 Sep 2009 13:02:26 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id C41DE3A68A9; Thu, 3 Sep 2009 13:02:06 -0700 (PDT) From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #18473 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 03 Sep 2009 13:02:06 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #18473] Resolved: Re: Protocol Action: 'Signaling LDP Label Advertisement Completion' to Proposed Standard We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Thu Sep 3 13:04:05 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n83K36XK010729 for ; Thu, 3 Sep 2009 13:03:07 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 8531D3A685A; Thu, 3 Sep 2009 13:02:47 -0700 (PDT) From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #18472 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 03 Sep 2009 13:02:47 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #18472] Resolved: Re: Protocol Action: 'Metering and marking behaviour of PCN-nodes' to Proposed Standard We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Thu Sep 3 13:04:07 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n83K3dqn010880 for ; Thu, 3 Sep 2009 13:03:40 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id E278C3A685A; Thu, 3 Sep 2009 13:03:19 -0700 (PDT) From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #18471 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 03 Sep 2009 13:03:19 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #18471] Resolved: Re: Protocol Action: 'Locating IEEE 802.21 Mobility Servers using DNS' to Proposed Standard We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Tue Sep 8 11:48:01 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n88IkWPV011547 for ; Tue, 8 Sep 2009 11:46:33 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 3E8C828C2FC; Tue, 8 Sep 2009 11:46:00 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090908184519.GB27954@isi.edu> References: <20090908184519.GB27954@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #18566 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 08 Sep 2009 11:46:01 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #18566] AutoReply: Adding the I-D String to Protocol/Document Action Messages? Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Adding the I-D String to Protocol/Document Action Messages?", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #18566]. Please include the string: [rt.amsl.com #18566] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings All! Would it be would possible to include the I-D string in the subject line of document/protocol actions? It would help us quickly identify relevant emails for particular drafts. We appreciate your consideration! Thanks! Sandy From wwwrun@core3.amsl.com Mon Sep 14 10:59:56 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n8EHwVpl015307 for ; Mon, 14 Sep 2009 10:58:32 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 062A228C1E3; Mon, 14 Sep 2009 10:57:45 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090914175747.GB19209@isi.edu> References: <20090914175747.GB19209@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #19530 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Mon, 14 Sep 2009 10:57:46 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #19530] AutoReply: Informational Independent Submission: draft-templin-ranger-07.txt Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Informational Independent Submission: draft-templin-ranger-07.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #19530]. Please include the string: [rt.amsl.com #19530] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- IESG, This document was submitted to the RFC Editor to be published as an Informational Independent Submission: draft-templin-ranger-07.txt. Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Four week timeout expires on 12 October 2009. Routing and Addressing in Next-Generation EnteRprises (RANGER) RANGER is an architectural framework for scalable routing and addressing in next generation enterprise networks. The term "enterprise network" within this context extends to a wide variety of use cases and deployment scenarios, where an "enterprise" can be as small as a SOHO network, as dynamic as a Mobile Ad-hoc Network, as complex as a multi-organizational corporation, or as large as the global Internet itself. Such networks will require an architected solution for the coordination of routing and addressing plans with accommodations for scalability, provider-independence, mobility, multi-homing and security. These considerations are particularly true for existing deployments, but the same principles apply even for clean-slate approaches. The RANGER architecture addresses these requirements, and provides a comprehensive framework for IPv6/IPv4 coexistence. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents From wwwrun@core3.amsl.com Mon Sep 14 16:20:20 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n8ENJltx017023 for ; Mon, 14 Sep 2009 16:19:48 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 54BD33A6976; Mon, 14 Sep 2009 16:19:00 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090914231713.GC19209@isi.edu> References: <20090914231713.GC19209@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #19537 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Mon, 14 Sep 2009 16:19:01 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #19537] AutoReply: Historic Independent Submission: draft-levy-sip-diversion-10.tx Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Historic Independent Submission: draft-levy-sip-diversion-10.tx", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #19537]. Please include the string: [rt.amsl.com #19537] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- IESG, This document was submitted to the RFC Editor to be published as a Historic Independent Submission: draft-levy-sip-diversion-10.txt. Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Four week timeout expires on 12 October 2009. Diversion Indication in SIP Note: This draft is being published as an RFC for the historical record and to provide a reference for later Informational RFCs. This document proposes an extension to the Session Initiation Protocol (SIP). This extension provides the ability for the called SIP user agent to identify from whom the call was diverted and why the call was diverted. The extension defines a general header, Diversion, which conveys the diversion information from other SIP user agents and proxies to the called user agent. This extension allows enhanced support for various features, including Unified Messaging, Third-Party Voicemail, and Automatic Call Distribution (ACD). SIP user agents and SIP proxies which receive diversion information may use this as supplemental information for feature invocation decisions. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents From wwwrun@core3.amsl.com Mon Sep 14 16:47:16 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n8ENl5Te026242 for ; Mon, 14 Sep 2009 16:47:06 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 643153A6838; Mon, 14 Sep 2009 16:46:19 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090914234610.GD19209@isi.edu> References: <20090914234610.GD19209@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #19538 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Mon, 14 Sep 2009 16:46:19 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #19538] AutoReply: Informational Independent Submission: draft-keromytis-keynote-x509-02.txt Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Informational Independent Submission: draft-keromytis-keynote-x509-02.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #19538]. Please include the string: [rt.amsl.com #19538] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- IESG, This document was submitted to the RFC Editor to be published as an Informational Independent Submission: draft-keromytis-keynote-x509-02.txt. Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Four week timeout expires on 12 October 2009. X.509 Key and Signature Encoding for the KeyNote Trust Management System This memo describes X.509 key identifiers and signature encoding for version 2 of the KeyNote trust-management system [KEYNOTE]. X.509 certificates [RFC3280] can be directly used in the Authorizer or Licensees field (or in both fields) in a KeyNote assertion, allowing for easy integration with protocols that already use X.509 certificates for authentication. In addition, the document defines additional signature types that use other hash functions (beyond the MD5 and SHA1 hash functions that are defined in [RFC2792]). NOTE: The draft lists the intended status as "Proposed." However, the document has been requested for publication as an Informational RFC. We will update the document to reflect "Informational" when/if it is accepted for publication. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents From wwwrun@core3.amsl.com Tue Sep 15 13:27:21 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n8FKQdlT001122 for ; Tue, 15 Sep 2009 13:26:40 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 399C13A6ABB; Tue, 15 Sep 2009 13:25:50 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #19538 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 15 Sep 2009 13:25:51 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #19538] Resolved: Informational Independent Submission: draft-keromytis-keynote-x509-02.txt We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Tue Sep 22 12:52:10 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n8MJp9Ck029405 for ; Tue, 22 Sep 2009 12:51:10 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 53A2C3A6867; Tue, 22 Sep 2009 12:50:04 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #19530 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 22 Sep 2009 12:50:04 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #19530] Resolved: Informational Independent Submission: draft-templin-ranger-07.txt We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Tue Sep 22 12:52:38 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n8MJqEPs029912 for ; Tue, 22 Sep 2009 12:52:15 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 8C7073A6925; Tue, 22 Sep 2009 12:51:09 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #19537 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 22 Sep 2009 12:51:09 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #19537] Resolved: Historic Independent Submission: draft-levy-sip-diversion-10.tx We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Tue Sep 22 17:26:06 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES, SUBJ_HAS_UNIQ_ID autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n8N0P3FY005225 for ; Tue, 22 Sep 2009 17:25:04 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id AA36A3A6A8D; Tue, 22 Sep 2009 17:23:55 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090923002334.GE17931@isi.edu> References: <20081027193437.5109B3A6A0D@core3.amsl.com> <20090923002334.GE17931@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #19752 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 22 Sep 2009 17:23:55 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #19752] AutoReply: Re: Informational RFC to be: draft-templin-autoconf-dhcp-18.txt Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Informational RFC to be: draft-templin-autoconf-dhcp-18.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #19752]. Please include the string: [rt.amsl.com #19752] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- All, Please note that the author has withdrawn this document from the RFC Editor queue. Secretariat, please note that the document may now expire. Please let us know if you have any questions. Thank you. RFC Editor/sg On Mon, Oct 27, 2008 at 12:34:37PM -0700, The IESG wrote: > The IESG has no problem with the publication of 'Virtual Enterprise > Traversal (VET)' as an Informational > RFC. > > The IESG would also like the IRSG or RFC-Editor to review the comments in > the datatracker > (https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14740&rfc_flag=0) > related to this document and determine whether or not they merit > incorporation into the document. Comments may exist in both the ballot > and the comment log. > > The IESG contact person is Ross Callon. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-templin-autoconf-dhcp-18.txt > > > The process for such documents is described at http://www.rfc-editor.org/indsubs.html. > > Thank you, > > The IESG Secretary > > Technical Summary > > Mobile Ad-hoc Networks (MANETs) connect routers on links with > asymmetric reachability characteristics, and may also connect to > other networks including the Internet. Routers in MANETs must have a > way to automatically provision IP addresses/prefixes and other > information. This document specifies a Virtual Enterprise Traversal > (VET) abstraction for autoconfiguration and operation of routers in > MANETs. > > Working Group Summary > > This document was submitted as an independent submission via the > RFC editor. However, it is closely related to the work in the MANET > WG, and is also very closely related to the work of the autoconf > working group (in the Internet area). This document appears > to partly overlap with one of the milestones in the autoconf > WG, which states: > Submit 'MANET router IPv6 prefix autoconfiguration mechanism' > to IESG for publication as Proposed Standard RFC > > Document Quality > > The document is an independent submission via the RFC editor. The > responsible AD is therefore reviewing this solely for overlap with > IETF work. > > Personnel > > This is an independent submission via the RFC editor. Ross Callon > has been acting as the AD to do the review for overlap with IETF > work. > > RFC Editor Note > > After considerable discussion and call for input from the WG, we > are recommending that the RFC editor publish the document, but with > an IESG note (see below). The IESG thinks that this work is related > to IETF work done in the autoconf WG, but this does not prevent > publishing. > > IESG Note: > > This RFC is not a candidate for any level of > Internet Standard. The IETF disclaims any knowledge of the > fitness of this RFC for any purpose and in particular notes that > the decision to publish is not based on IETF review for such > things as security, congestion control, or inappropriate > interaction with deployed protocols. The RFC Editor has chosen to > publish this document at its discretion. Readers of this RFC > should exercise caution in evaluating its value for implementation > and deployment. See RFC 3932 for more information. > > Note that the IETF AUTOCONF Working Group is working on a > a similar protocol solution that may become available in the > future. From wwwrun@core3.amsl.com Thu Sep 24 09:51:34 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES, SUBJ_HAS_UNIQ_ID autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n8OGooLJ019218 for ; Thu, 24 Sep 2009 09:50:51 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 5B7A93A6A8C; Thu, 24 Sep 2009 09:49:41 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090924164949.GB13063@isi.edu> References: <20081027193437.5109B3A6A0D@core3.amsl.com> <20090923002334.GE17931@isi.edu> <20090924164949.GB13063@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #19793 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 24 Sep 2009 09:49:41 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #19793] AutoReply: Re: Informational RFC to be: draft-templin-autoconf-dhcp-18.txt Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Informational RFC to be: draft-templin-autoconf-dhcp-18.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #19793]. Please include the string: [rt.amsl.com #19793] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings All, Our apologies for the confusion, but the author has informed us that he did not intend to withdraw the document. This document has been moved back into AUTH48, and will be published once the copyright notice for the Independent stream has been determined. Secretariat, please do not expire this draft. Thank you. RFC Editor/sg On Tue, Sep 22, 2009 at 05:23:34PM -0700, RFC Editor wrote: > All, > > Please note that the author has withdrawn this document from the RFC > Editor queue. > > Secretariat, please note that the document may now expire. > > Please let us know if you have any questions. > > Thank you. > > RFC Editor/sg > > > On Mon, Oct 27, 2008 at 12:34:37PM -0700, The IESG wrote: > > The IESG has no problem with the publication of 'Virtual Enterprise > > Traversal (VET)' as an Informational > > RFC. > > > > The IESG would also like the IRSG or RFC-Editor to review the comments in > > the datatracker > > (https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14740&rfc_flag=0) > > related to this document and determine whether or not they merit > > incorporation into the document. Comments may exist in both the ballot > > and the comment log. > > > > The IESG contact person is Ross Callon. > > > > A URL of this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-templin-autoconf-dhcp-18.txt > > > > > > The process for such documents is described at http://www.rfc-editor.org/indsubs.html. > > > > Thank you, > > > > The IESG Secretary > > > > Technical Summary > > > > Mobile Ad-hoc Networks (MANETs) connect routers on links with > > asymmetric reachability characteristics, and may also connect to > > other networks including the Internet. Routers in MANETs must have a > > way to automatically provision IP addresses/prefixes and other > > information. This document specifies a Virtual Enterprise Traversal > > (VET) abstraction for autoconfiguration and operation of routers in > > MANETs. > > > > Working Group Summary > > > > This document was submitted as an independent submission via the > > RFC editor. However, it is closely related to the work in the MANET > > WG, and is also very closely related to the work of the autoconf > > working group (in the Internet area). This document appears > > to partly overlap with one of the milestones in the autoconf > > WG, which states: > > Submit 'MANET router IPv6 prefix autoconfiguration mechanism' > > to IESG for publication as Proposed Standard RFC > > > > Document Quality > > > > The document is an independent submission via the RFC editor. The > > responsible AD is therefore reviewing this solely for overlap with > > IETF work. > > > > Personnel > > > > This is an independent submission via the RFC editor. Ross Callon > > has been acting as the AD to do the review for overlap with IETF > > work. > > > > RFC Editor Note > > > > After considerable discussion and call for input from the WG, we > > are recommending that the RFC editor publish the document, but with > > an IESG note (see below). The IESG thinks that this work is related > > to IETF work done in the autoconf WG, but this does not prevent > > publishing. > > > > IESG Note: > > > > This RFC is not a candidate for any level of > > Internet Standard. The IETF disclaims any knowledge of the > > fitness of this RFC for any purpose and in particular notes that > > the decision to publish is not based on IETF review for such > > things as security, congestion control, or inappropriate > > interaction with deployed protocols. The RFC Editor has chosen to > > publish this document at its discretion. Readers of this RFC > > should exercise caution in evaluating its value for implementation > > and deployment. See RFC 3932 for more information. > > > > Note that the IETF AUTOCONF Working Group is working on a > > a similar protocol solution that may become available in the > > future. From wwwrun@core3.amsl.com Fri Sep 25 14:12:04 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES, SUBJ_HAS_UNIQ_ID autolearn=no version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n8PLBKPb016910 for ; Fri, 25 Sep 2009 14:11:21 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 4BD473A693D; Fri, 25 Sep 2009 14:10:08 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #19793 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 25 Sep 2009 14:10:08 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #19793] Resolved: Re: Informational RFC to be: draft-templin-autoconf-dhcp-18.txt We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Fri Sep 25 16:45:50 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n8PNirxO012955 for ; Fri, 25 Sep 2009 16:44:54 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id BBE943A68A6; Fri, 25 Sep 2009 16:43:40 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20090925234336.GD14234@isi.edu> References: <20090925234336.GD14234@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #19853 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 25 Sep 2009 16:43:40 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #19853] AutoReply: RFC 222 (update) Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "RFC 222 (update)", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #19853]. Please include the string: [rt.amsl.com #19853] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, Please note that we have just made a correction to rfc222.txt. Please take the necessary steps to update your files accordingly. FYI: RFCs are never updated once they are published. The exception to this rule are those RFCs that were lost in a system transition long ago and have been transcribed to create a complete online history. There was an error in the transcription of rfc222.txt. Please let us know if you have any questions. Thanks! Sandy From wwwrun@core3.amsl.com Mon Sep 28 12:57:08 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n8SJtxVQ008938 for ; Mon, 28 Sep 2009 12:56:00 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 4CDB23A69AD; Mon, 28 Sep 2009 12:54:40 -0700 (PDT) From: "Glen via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #19853 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: glen@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Mon, 28 Sep 2009 12:54:40 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #19853] Resolved: RFC 222 (update) We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Tue Oct 6 15:23:48 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n96MMbOH011313 for ; Tue, 6 Oct 2009 15:22:38 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 4382928C0F7; Tue, 6 Oct 2009 15:20:58 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20091006222129.GA11318@isi.edu> References: <20091006192913.E1B8C3A6833@core3.amsl.com> <20091006222129.GA11318@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #20103 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 06 Oct 2009 15:20:58 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #20103] AutoReply: Re: Protocol Action: 'Sieve Email Filtering: MIME part Tests, Iteration, Extraction, Replacement and Enclosure' to Proposed Standard Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Sieve Email Filtering: MIME part Tests, Iteration, Extraction, Replacement and Enclosure' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #20103]. Please include the string: [rt.amsl.com #20103] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Tue, Oct 06, 2009 at 12:29:13PM -0700, The IESG wrote: > The IESG has approved the following document: > > - 'Sieve Email Filtering: MIME part Tests, Iteration, Extraction, > Replacement and Enclosure ' > as a Proposed Standard > > > This document is the product of the Sieve Mail Filtering Language Working Group. > > The IESG contact persons are Lisa Dusseault and Alexey Melnikov. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sieve-mime-loop-09.txt > > Technical Summary > > This document defines extensions to the Sieve email filtering > language to permit analysis and manipulation of the MIME body parts > of an email message. > > Working Group Summary > > Majority of posted comments were addressed in the latest revision, for > the remaining there was no wide WG support in favor of changes. > > > Document Quality > > At least 2 server vendors are interested in implementing extensions > specified in the document. > > At least 6 people have reviewed the document. > > Personnel > > Aaron Stone is the document shepherd. Lisa Dusseault is the sponsoring > AD. > > RFC Editor Note > > In Section 3, change the 2nd paragraph to read: > > OLD: > The iterator can be terminated prematurely by a new Sieve command, > "break". > > NEW: > The iterator can be terminated prematurely by a new Sieve control > ^^^^^^^ > command, "break". > > Add a new paragraph before the last paragraph of section 3: > > If no name is given in a "break" command (i.e. the :name is omitted), > the break command terminates the closest enclosing loop. > > In Section 4.1, > OLD > When the ":mime" tagged argument is present in the "header" test, it > will parse the MIME header lines in the message so that tests can be > performed on specific elements. > NEW > When the ":mime" tagged argument is present in the "header" test, it > will parse the MIME header lines in the message so that tests can be > performed on specific elements. The ":anychild" tagged argument may > only appear when the ":mime" tagged argument is present, and only > modifies the semantics of the ":mime" tagged argument. That is, presence > of the ":anychild" in absence of ":mime" is an error. > > In Section 4.2, change the 5th paragraph to read: > > OLD: > That is, > > the use of "address" with no ":mime" and ":anychild" tagged > ^^^^^^^ > argument is the test defined in [RFC5228], i.e. it will *only* > ^ > operate on top level header fields, whether it is inside > "foreverypart" or not. > > NEW: > That is, > > the use of "address" when both the ":mime" and ":anychild" tagged > ^^^^^^^^^^^^^ > arguments are omitted is the test defined in [RFC5228], > ^^^^^^^^^^^^^ > i.e. it will *only* > operate on top level header fields, whether it is inside > "foreverypart" or not. > > In Section 4.3 change the 5th paragraph to read: > > OLD: > That is, > > the use of "exists" with no ":mime" and ":anychild" tagged > argument is the test defined in [RFC5228], i.e. it will *only* > operate on top level header fields, whether it is inside > "foreverypart" or not. > NEW: > That is, > > the use of "exists" when both the ":mime" and ":anychild" tagged > arguments are omitted is the test defined in [RFC5228], > i.e. it will *only* > operate on top level header fields, whether it is inside > "foreverypart" or not. > > > Also, please change "SIEVE" to "Sieve" (in 3 places in the document). From wwwrun@core3.amsl.com Tue Oct 6 15:31:41 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n96MVIwb015314 for ; Tue, 6 Oct 2009 15:31:19 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 99A2828C213; Tue, 6 Oct 2009 15:29:39 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #20103 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 06 Oct 2009 15:29:39 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #20103] Resolved: Re: Protocol Action: 'Sieve Email Filtering: MIME part Tests, Iteration, Extraction, Replacement and Enclosure' to Proposed Standard We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Mon Oct 12 14:01:10 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n9CL0iFj017519 for ; Mon, 12 Oct 2009 14:00:45 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 249553A6805; Mon, 12 Oct 2009 14:00:39 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20091012210008.GA21346@isi.edu> References: <20091012195931.6C7873A6963@core3.amsl.com> <20091012210008.GA21346@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #20308 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Mon, 12 Oct 2009 14:00:40 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #20308] AutoReply: Re: Protocol Action: 'Updated IANA Considerations for Diameter Command Code Allocations' to Proposed Standard Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Updated IANA Considerations for Diameter Command Code Allocations' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #20308]. Please include the string: [rt.amsl.com #20308] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Mon, Oct 12, 2009 at 12:59:31PM -0700, The IESG wrote: > The IESG has approved the following document: > > - 'Updated IANA Considerations for Diameter Command Code Allocations ' > as a Proposed Standard > > > This document is the product of the Diameter Maintenance and Extensions Working Group. > > The IESG contact persons are Ron Bonica and Dan Romascanu. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-cmd-iana-01.txt > > Technical Summary > > The Diameter Base specification, described in RFC 3588, provides a number > of ways to extend Diameter, with new Diameter commands, i.e. messages used > by Diameter applications, and applications as the most extensive > enhancements. RFC 3588 illustrates the conditions that lead to the need > to define a new Diameter application or a new command code. Depending on > the scope of the Diameter extension IETF actions are necessary. Although > defining new Diameter applications does not require IETF consensus, > defining new Diameter commands requires IETF consensus per RFC 3588. This > has lead to questionable design decisions by other Standards Development > Organizations which chose to define new applications on existing commands > rather than asking for assignment of new command codes for the pure > purpose of avoiding bringing their specifications to the IETF. In some > cases interoperability problems were causes as an effect of the poor > design caused by overloading existing commands. > > This document aligns the extensibility rules of Diameter application with > the Diameter commands offering ways to delegate work on Diameter to other > SDOs to extend Diameter in a way that does not lead to poor design > choices. > > Working Group Summary > > This document is the product of the DIME working group. The extensibility > rules of Diameter have been investigated by a design team and the > alignment of policy for extending Diameter applications and Diameter > commands has been agreed. > > Document Quality > > This document focuses on the description of the allocation policy change > in the IANA consideration section and has been discussed for some time. > > Personnel > > Victor Fajardo is the document shepherd for this document. > > Ron Bonica is the responsible AD. > > > RFC Editor Note > > Section 3 content should be modified as follows: > > OLD > > This document modifies the IANA allocation of Diameter Command Codes > in relationship to RFC 3588. This process change itself does not > raise security concerns, but the command codes space is split into a > standards commands space and a vendor-specific command codes space, > the later being allocated on a First Come, First Served basis by IANA > at the request of vendors or other standards organizations. Whenever > work gets delegated to organizations outside the IETF there is always > the chance that fewer security reviews are conducted and hence the > quality of the resulting protocol document is weaker compared to the > rather extensive reviews performed in the IETF. The members of the > DIME working group are aware of the tradeoff between better > specification quality and the desire to offload work (e.g., to reduce > the workload in the IETF) to other organizations. Other > organizations are therefore made responsible for the quality of the > specifications they produce. > > NEW > > This document modifies the IANA allocation of Diameter Command Codes > in relationship to RFC 3588. This process change itself does not > raise security concerns, but the command codes space is split into a > standards commands space and a vendor-specific command codes space, > the later being allocated on a First Come, First Served basis by IANA > at the request of vendors or other standards organizations. Whenever > work gets delegated to organizations outside the IETF there is always > the chance that security reviews are conducted in different manner > and the criteria and style of the reviews are different than the > reviews > performed in the IETF. The members of the DIME working group are > aware > of the risks involved in using different security and quality review > processes > and the desire to offload work (e.g., to reduce the workload in the > IETF) to > other organizations. Other organizations are therefore made > responsible for > the quality of the specifications they produce. From wwwrun@core3.amsl.com Mon Oct 12 14:02:15 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n9CL1X9m017762 for ; Mon, 12 Oct 2009 14:01:34 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id F359D28C1CC; Mon, 12 Oct 2009 14:01:31 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20091012210102.GB21346@isi.edu> References: <20091012164846.DCFF23A67D6@core3.amsl.com> <20091012210102.GB21346@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #20309 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Mon, 12 Oct 2009 14:01:31 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #20309] AutoReply: Re: Document Action: 'IPv4 Address Blocks Reserved for Documentation' to Informational RFC Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'IPv4 Address Blocks Reserved for Documentation' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #20309]. Please include the string: [rt.amsl.com #20309] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Mon, Oct 12, 2009 at 09:48:46AM -0700, The IESG wrote: > The IESG has approved the following document: > > - 'IPv4 Address Blocks Reserved for Documentation ' > as an Informational RFC > > This document has been reviewed in the IETF but is not the product of an > IETF Working Group. > > The IESG contact person is Russ Housley. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-iana-ipv4-examples-02.txt > > Technical Summary > > Several IPv4 unicast address blocks are reserved for use in examples > in specifications and other documents. This document describes the > use of these blocks. > > RFC 1166 reserves the first of these address blocks (192.0.2.0/24). > Other address blocks have recently been allocated for examples, > primarily to ease the writing of examples involving addresses from > multiple networks. > > Working Group Summary > > This document is not the product of any IETF WG. > > Protocol Quality > > The document was reviewed by Russ Housley for the IESG. From wwwrun@core3.amsl.com Mon Oct 12 14:02:19 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n9CL1f5i017808 for ; Mon, 12 Oct 2009 14:01:42 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 4C9D028C1CC; Mon, 12 Oct 2009 14:01:39 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20091012210115.GC21346@isi.edu> References: <20091012142155.D66C228C1FE@core3.amsl.com> <20091012210115.GC21346@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #20310 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Mon, 12 Oct 2009 14:01:40 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #20310] AutoReply: Re: Document Action: 'Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions' to Informational RFC Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #20310]. Please include the string: [rt.amsl.com #20310] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Mon, Oct 12, 2009 at 07:21:55AM -0700, The IESG wrote: > The IESG has approved the following document: > > - 'Guidelines for Considering Operations and Management of New Protocols > and Protocol Extensions ' > as an Informational RFC > > > This document is the product of the Operations and Management Area Working Group. > > The IESG contact persons are Dan Romascanu and Ron Bonica. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-opsawg-operations-and-management-09.txt > > Technical Summary > > New protocols or protocol extensions are best designed with due > consideration of functionality needed to operate and manage the > protocols. Retrofitting operations and management is sub-optimal. > The purpose of this document is to provide guidance to authors and > reviewers of documents defining new protocols or protocol extensions, > about covering aspects of operations and management that should be > considered. > > Working Group Summary > > There was consensus in the working group to publish this document. > > Document Quality > > > The document was reviewed by a number of experts with operational and > management experience. An IETF Last Call was run and comments > received during the Last Call were incorporated in the final > version. > > Personnel > > Scott Bradner is the Document Shepherd for this document. Dan > Romascanu is the Responsible Area Director. > > RFC Editor Note > > 1. In Section 1.2: > > OLD: > > This document discusses the importance of considering operations and > management by setting forth a list of guidelines and a checklist of > questions to consider, > > NEW: > > This document discusses the importance of considering operations and > management by setting forth a list of guidelines and a checklist of > questions to consider (see Appendix A), > > 2. In Section 7 > > s/Adrian Farrell/Adrian Farrel/ > > 3. In Section 1.6: > > OLD: > This document is a set of guidelines > based on current practices of protocol designers and operators. > This document does not describe requirements, so the key words from > RFC2119 have no place here. > NEW: > This informational document is a set of guidelines > based on current practices of **some** protocol designers and > operators. This > document is biased toward router operations and management and some > advice > may not be directly applicable to protocols with a different purpose, > such as > application server protocols. This document **does not** describe > interoperability requirements, so the capitalized key words from > RFC2119 do not apply here. > > 4. Add in Section 4: > > This document does not describe interoperability requirements, but rather > describes practices that are useful to be followed in dealing with > manageability aspects in the IETF documents, so the capitalized keywords > from RFC2119 do not apply here. Any occurrence of words like 'must' or > 'should' needs to be interpreted only in the context of their natural > English language meaning. > > 5. In section 1.5: > > OLD: > > SNMP [RFC3410], > > SYSLOG [RFC5424], > > RADIUS [RFC2865], > > DIAMETER [RFC3588], > > NETCONF [RFC4741], > > IPFIX [RFC5101]. > > NEW: > > Simple Network Management Protocol - SNMP [RFC3410], > > SYSLOG [RFC5424], > > Remote Authentication Dial In User Service - RADIUS [RFC2865], > > DIAMETER [RFC3588], > > Network Configuration Protocol - NETCONF [RFC4741], > > IP Flow Information Export - IPFIX [RFC5101]. > > 6. in Section 1.4 > > OLD: > > One issue discussed was the user-unfriendliness of the binary format > of SNMP [RFC3410] and COPS Usage for Policy Provisioning (COPS-PR) > [RFC3084], and it was recommended that the IETF explore an XML-based > Structure of Management Information, and an XML-based protocol for > configuration. > > NEW: > > One issue discussed was the user-unfriendliness of the binary format > of SNMP [RFC3410] and Common Open Policy Service (COPS) Usage for > Policy Provisioning (COPS-PR)[RFC3084], and it was recommended that > the IETF explore an XML-based Structure of Management Information, > and an XML-based protocol for configuration. > > 7. in Section 3.1: > > OLD: > > Other Standard Development Organizations (e.g. DMTF, TMF) > > NEW: > > Other Standard Development Organizations (e.g. the Distributed Management > Task Force - DMTF, the Tele-Management Forum - TMF) > > 8. In Section 3.3.2: > > OLD: > > Would some threshold-based mechanisms, such as RMON events/alarms or > the EVENT-MIB, be useable to help determine error conditions? > > NEW: > > Would some threshold-based mechanisms, such as Remote Monitoring (RMON) > events/alarms or the EVENT-MIB, be useable to help determine error > conditions? > > 9. In Section 3.4: > > OLD: > > There are two parts to this: 1. An NMS system could optimize access > control lists (ACLs) for performance reasons > > NEW: > > There are two parts to this: 1. A Network Management System (NMS) could > optimize access control lists (ACLs) for performance reasons From wwwrun@core3.amsl.com Tue Oct 13 07:16:55 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n9DEGJSe011637 for ; Tue, 13 Oct 2009 07:16:19 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 3500E28C232; Tue, 13 Oct 2009 07:16:16 -0700 (PDT) From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #20308 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 13 Oct 2009 07:16:17 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #20308] Resolved: Re: Protocol Action: 'Updated IANA Considerations for Diameter Command Code Allocations' to Proposed Standard We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Tue Oct 13 07:17:52 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n9DEH9v4011959 for ; Tue, 13 Oct 2009 07:17:10 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id D208C28C315; Tue, 13 Oct 2009 07:17:07 -0700 (PDT) From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #20309 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 13 Oct 2009 07:17:07 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #20309] Resolved: Re: Document Action: 'IPv4 Address Blocks Reserved for Documentation' to Informational RFC We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Tue Oct 13 07:21:07 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n9DEKNMn013641 for ; Tue, 13 Oct 2009 07:20:23 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 3C95A3A682B; Tue, 13 Oct 2009 07:20:21 -0700 (PDT) From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #20310 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 13 Oct 2009 07:20:21 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #20310] Resolved: Re: Document Action: 'Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions' to Informational RFC We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Wed Oct 14 14:46:03 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n9ELjKkQ014339 for ; Wed, 14 Oct 2009 14:45:21 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 7BF673A69C4; Wed, 14 Oct 2009 14:45:17 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20091014214452.GA20924@isi.edu> References: <20091014214452.GA20924@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #20388 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 14 Oct 2009 14:45:17 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #20388] AutoReply: Informational Independent Submission: draft-braden-independent-submission-01.txt Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Informational Independent Submission: draft-braden-independent-submission-01.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #20388]. Please include the string: [rt.amsl.com #20388] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- IESG, This document was submitted to the RFC Editor to be published as an Informational Independent Submission: draft-braden-independent-submission-01.txt. Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Four week timeout expires on 11 November 2009. Procedures for Rights Handling in the RFC Independent Stream This document specifies the procedures by which authors of RFC Independent Stream documents grant the community "incoming" rights for copying and using the text. It also specifies the "outgoing" rights the community grants to readers and users of those documents, and it requests that the IETF Trust manage the outgoing rights to effect this result. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents From wwwrun@core3.amsl.com Thu Oct 15 09:25:26 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n9FGOiBw010785 for ; Thu, 15 Oct 2009 09:24:45 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 341E23A68F5; Thu, 15 Oct 2009 09:24:39 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #20388 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 15 Oct 2009 09:24:40 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #20388] Resolved: Informational Independent Submission: draft-braden-independent-submission-01.txt We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Mon Oct 19 13:09:37 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n9JK8KIN025640 for ; Mon, 19 Oct 2009 13:08:21 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 588DB3A6825; Mon, 19 Oct 2009 13:08:12 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20091019200638.GF26124@isi.edu> References: <20091019200638.GF26124@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #20538 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Mon, 19 Oct 2009 13:08:12 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #20538] AutoReply: Experimental Independent Submission: draft-wu-softwire-4over6-03.txt Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Experimental Independent Submission: draft-wu-softwire-4over6-03.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #20538]. Please include the string: [rt.amsl.com #20538] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- IESG, This document was submitted to the RFC Editor to be published as an Experimental Independent Submission: draft-wu-softwire-4over6-03.txt. Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Five week timeout expires on 23 November 2009. Note that we have added an extra week because of the upcoming IETF proceedings. 4over6 Transit Solution using IP Encapsulation and MP-BGP Extensions The emerging and growing deployment of IPv6 networks will introduce cases where connectivity with IPv4 networks crossing IPv6 transit backbones is desired. This document describes a mechanism for automatic discovery and creation of IPv4 over IPv6 tunnels via extensions to multi- protocol BGP. It is targeted at connecting islands of IPv4 networks across an IPv6-only backbone without the need for a manually configured overlay of tunnels. The mechanisms described in this document have been implemented, tested and deployed on the large research IPv6 network in China. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents From wwwrun@core3.amsl.com Thu Oct 22 13:54:34 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n9MKrG8U026982 for ; Thu, 22 Oct 2009 13:53:16 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 9EA063A68C3; Thu, 22 Oct 2009 13:53:05 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #20538 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 22 Oct 2009 13:53:05 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #20538] Resolved: Experimental Independent Submission: draft-wu-softwire-4over6-03.txt We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Thu Oct 29 11:56:34 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n9TItVSU009841 for ; Thu, 29 Oct 2009 11:55:32 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 7C4203A6A13; Thu, 29 Oct 2009 11:55:14 -0700 (PDT) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20091029185411.GE8411@isi.edu> References: <20091029172119.7A5DD3A6882@core3.amsl.com> <20091029185411.GE8411@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #20881 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 29 Oct 2009 11:55:14 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #20881] AutoReply: Re: Document Action: 'POP3 Support for UTF-8' to Experimental RFC Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'POP3 Support for UTF-8' to Experimental RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.amsl.com #20881]. Please include the string: [rt.amsl.com #20881] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Thu, Oct 29, 2009 at 10:21:19AM -0700, The IESG wrote: > The IESG has approved the following document: > > - 'POP3 Support for UTF-8 ' > as an Experimental RFC > > > This document is the product of the Email Address Internationalization Working Group. > > The IESG contact persons are Alexey Melnikov and Lisa Dusseault. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-eai-pop-09.txt > > Technical Summary > > This specification extends the Post Office Protocol version 3 (POP3) > to support un-encoded international characters in user names, > passwords, mail addresses, message headers, and protocol-level > textual error strings. > > Working Group Summary > > The WG explored a couple of different designs for this > extension. The path chosen (a global switch to UTF-8 only mode) > has the consensus of the WG. > > Document Quality > > At least one existing implementation of the document exists. > > Personnel > > Harald Alvestrand is the document shepherd. Alexey Melnikov > is the responsible AD. > > RFC Editor Note > > In Section 3.2, change the 4th paragraph to read: > > OLD: > When applying SASLprep [RFC4013], servers MUST reject UTF-8 user > names or passwords which contain a Unicode character listed in > section 2.3 of SASLprep [RFC4013]. > > NEW: > When applying SASLprep [RFC4013], servers MUST reject UTF-8 user > names or passwords which contain a Unicode character listed in > section 2.3 of SASLprep [RFC4013]. > When applying SASLPrep to the USER argument, to the PASS argument > or to the APOP username argument, a compliant server or client MUST > treat them as a query string (i.e., unassigned Unicode codepoints are > allowed). When applying SASLPrep to the APOP password argument, a > compliant server or client MUST treat them as a stored string (i.e., > unassigned Unicode codepoints are prohibited). From wwwrun@core3.amsl.com Thu Oct 29 12:03:49 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n9TJ21I1012661 for ; Thu, 29 Oct 2009 12:02:02 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id CC9043A6A24; Thu, 29 Oct 2009 12:01:41 -0700 (PDT) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.amsl.com RT-Ticket: rt.amsl.com #20881 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 29 Oct 2009 12:01:41 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.amsl.com #20881] Resolved: Re: Document Action: 'POP3 Support for UTF-8' to Experimental RFC We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Sun Nov 8 17:18:14 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id nA91HaPn011702 for ; Sun, 8 Nov 2009 17:17:37 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 1F0353A6A36; Sun, 8 Nov 2009 17:17:09 -0800 (PST) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20091109011612.GA18296@isi.edu> References: <20091109011612.GA18296@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #21175 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Sun, 08 Nov 2009 17:17:10 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.ietf.org #21175] AutoReply: Informational Independent Submission: draft-nsri-aria-02.txt Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Informational Independent Submission: draft-nsri-aria-02.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #21175]. Please include the string: [rt.ietf.org #21175] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- IESG, This document was submitted to the RFC Editor to be published as an Informationsl Independent Submission: draft-nsri-aria-02.txt. Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Five week timeout expires on 14 December 2009. Please note that we included an additional week because of the ongoing IETF. A Description of the ARIA Encryption Algorithm This document describes the ARIA encryption algorithm. ARIA is a 128-bit block cipher with 128-, 192-, and 256-bit keys. The algorithm consists of key scheduling part and data randomizing part. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents The document draft-nsri-aria-02 "A Description of the ARIA Encryption Algorithm" has been accepted for publication. Please place it in TO state and send it to the IESG. Independent Submissions Editor/bb ----- End forwarded message ----- From wwwrun@core3.amsl.com Tue Nov 10 21:17:22 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id nAB5GT4c003133 for ; Tue, 10 Nov 2009 21:16:30 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 45A0B28C276; Tue, 10 Nov 2009 21:16:00 -0800 (PST) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20091111051450.GA12815@isi.edu> References: <20091111051450.GA12815@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #21297 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 10 Nov 2009 21:16:01 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.ietf.org #21297] AutoReply: Informational Independent Submission: draft-mavrogiannopoulos-rfc5081bis-03.txt Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Informational Independent Submission: draft-mavrogiannopoulos-rfc5081bis-03.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #21297]. Please include the string: [rt.ietf.org #21297] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- IESG, This document was submitted to the RFC Editor to be published as an Informational Independent Submission: draft-mavrogiannopoulos-rfc5081bis-03.txt. NOTE: The author intends for this document to obsolete RFC 5081. RFC 5081 is an Experimental RFC produced by the Transport Layer Security working group. So, the document would be changing streams as well as status (i.e., IETF stream --> Independent stream and Experimental --> Informational). Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Five week timeout expires on 16 December 2009. Please note that we have included an additional week because of the current IETF proceedings. Using OpenPGP Keys for Transport Layer Security (TLS) Authentication This memo proposes extensions to the Transport Layer Security (TLS) protocol to support the OpenPGP key format. The extensions discussed here include a certificate type negotiation mechanism, and the required modifications to the TLS Handshake Protocol. This memo replaces the Experimental [RFC5081]. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents From wwwrun@core3.amsl.com Thu Nov 19 13:39:29 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id nAJLcenq026118 for ; Thu, 19 Nov 2009 13:38:41 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 2C8F83A6855; Thu, 19 Nov 2009 13:38:41 -0800 (PST) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #21297 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 19 Nov 2009 13:38:42 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.ietf.org #21297] Resolved: Informational Independent Submission: draft-mavrogiannopoulos-rfc5081bis-03.txt We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Thu Nov 19 13:39:53 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id nAJLdIlc026331 for ; Thu, 19 Nov 2009 13:39:19 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 3BCD53A68DA; Thu, 19 Nov 2009 13:39:19 -0800 (PST) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #21175 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 19 Nov 2009 13:39:20 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.ietf.org #21175] Resolved: Informational Independent Submission: draft-nsri-aria-02.txt We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Mon Nov 30 12:05:17 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id nAUK4dO2016632 for ; Mon, 30 Nov 2009 12:04:39 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 77ED13A6994; Mon, 30 Nov 2009 12:04:45 -0800 (PST) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20091130200224.GC14754@isi.edu> References: <20091130200224.GC14754@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #21910 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Mon, 30 Nov 2009 12:04:45 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.ietf.org #21910] AutoReply: Experimental Independent Submission: draft-zeilenga-ldap-txn-15.txt Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Experimental Independent Submission: draft-zeilenga-ldap-txn-15.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #21910]. Please include the string: [rt.ietf.org #21910] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- IESG, This document was submitted to the RFC Editor to be published as an Experimental Independent Submission: draft-zeilenga-ldap-txn-15.txt. Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Four week timeout expires on 28 December 2009. LDAP Transactions Lightweight Directory Access Protocol (LDAP) update operations, such as Add, Delete, and Modify operations, have atomic, consistency, isolation, durability (ACID) properties. Each of these update operations act upon an entry. It is often desirable to update two or more entries in a single unit of interaction, a transaction. Transactions are necessary to support a number of applications including resource provisioning. This document extends LDAP to support transactions. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents From wwwrun@core3.amsl.com Mon Nov 30 13:35:09 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id nAULYLTh022479 for ; Mon, 30 Nov 2009 13:34:21 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 9ED6C28C11A; Mon, 30 Nov 2009 13:34:27 -0800 (PST) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20091130213304.GE14754@isi.edu> References: <20091111051450.GA12815@isi.edu> <4B142B2E.6080508@gnutls.org> <20091130213304.GE14754@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #21916 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Mon, 30 Nov 2009 13:34:27 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.ietf.org #21916] AutoReply: Re: Informational Independent Submission: draft-mavrogiannopoulos-rfc5081bis-03.txt Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Informational Independent Submission: draft-mavrogiannopoulos-rfc5081bis-03.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #21916]. Please include the string: [rt.ietf.org #21916] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Nikos, Thank you for the update. We have removed your document from our queue. RFC Editor/sg On Mon, Nov 30, 2009 at 10:29:34PM +0200, Nikos Mavrogiannopoulos wrote: > RFC Editor wrote: > > IESG, > > > > This document was submitted to the RFC Editor to be published as an > > Informational Independent Submission: > > draft-mavrogiannopoulos-rfc5081bis-03.txt. > > > > NOTE: The author intends for this document to obsolete RFC 5081. RFC > > 5081 is an Experimental RFC produced by the Transport Layer Security > > working group. So, the document would be changing streams as well as > > status (i.e., IETF stream --> Independent stream and Experimental --> > > Informational). > > > > Please let us know if this document conflicts with the IETF standards > > process or other work being done in the IETF community. > > Hello, > I withdraw this draft from the independent submission process. It will > be submitted again as an AD-sponsored document. > > best regards, > Nikos From wwwrun@core3.amsl.com Mon Nov 30 13:52:10 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id nAULobMT028806 for ; Mon, 30 Nov 2009 13:50:38 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id CA2DD3A692C; Mon, 30 Nov 2009 13:50:43 -0800 (PST) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20091130215001.GF14754@isi.edu> References: <20080915210549.28E263A6AC4@core3.amsl.com> <20091130215001.GF14754@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #21917 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Mon, 30 Nov 2009 13:50:43 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.ietf.org #21917] AutoReply: Experimental RFC to be: draft-hajjeh-tls-identity-protection-09.txt Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Experimental RFC to be: draft-hajjeh-tls-identity-protection-09.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #21917]. Please include the string: [rt.ietf.org #21917] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- IESG, This document was submitted to the RFC Editor to be published as an Experimental Independent Submission: draft-hajjeh-tls-identity-protection-09.txt. Please note that this document was sent for a review in August 2008, and that the IESG had sent a DNP request (see email below). However, subsequent discussion indicated that, rather than the RFC Editor "ignoring" the DNP request, that the IESG would be less unhappy with the publication of the document if the IANA Considerations section was removed from the document. The author has removed the IANA Considerations, and we therefore submit the document for re-review. Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Credential Protection Ciphersuites for Transport Layer Security (TLS) This document defines a set of cipher suites to add client credential protection to the Transport Layer Security (TLS) protocol. By negotiating one of those ciphersuites, the TLS clients will be able to determine for themselves when, how, to what extent and for what purpose information about them is communicated to others. The ciphersuites defined in this document can be used only when public key certificates are used in the client authentication process. Four week timeout expires on 28 December 2009. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents On Mon, Sep 15, 2008 at 02:05:49PM -0700, The IESG wrote: > The IESG recommends that 'Credential Protection Ciphersuites for > Transport Layer Security (TLS)' > NOT be published as an an > Experimental RFC. > > The IESG contact person is Pasi Eronen. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-hajjeh-tls-identity-protection-06.txt > > > The process for such documents is described at http://www.rfc-editor.org/indsubs.html. > > Thank you, > > The IESG Secretary > > Technical Summary > > When a TLS connection is authenticated using certificates, the > certificates are normally sent before encryption is actived, and > thus an eavesdropper can see them, leading to privacy concerns > especially when client certificates are used. To address these > concerns, TLS also supports a longer handshake where the server is > authenticated first, and the client's certificate is then sent > encrypted. > > This draft specifies a new handshake variation for the same purpose > (client's certificate is sent encrypted). Compared to the existing > mechanism, this new variation uses two roundtrips less, and may > need slightly fewer cryptographic operations. > > Working Group Summary > > This document is not the result of any IETF Working Group. It is > an independent submission to the RFC Editor. > > Some background: > > This draft is a continuation of older draft with different name > (draft-urien-badra-eap-tls-identity-protection). Around the same > general topic area, the authors also have couple of academic papers > ("Hiding User Credentials during the TLS authentication phase" in > NTMS 2007, and "Adding Identity Protection to EAP-TLS Smartcards" > in IEEE WCNC 2007), and a patent application (WO/2007/115982) > (which the authors say doesn't apply to this draft -- there has > been no statement from the patent owner). > > The Internet-Drafts were briefly discussed in late 2006 in EMU and > TLS WGs, but there was basically zero interest, since there was no > evidence suggesting that the current mechanism -- which is already > standardized, implemented, and deployed -- needed optimization in > real-world scenarios. Thus, it was felt that introducing another > mechanism for the same purpose would be just unnecessary complexity > with possible impacts on interoperability. > > In June 2007, the authors asked Dan Romascanu if he'd sponsor the > document as an AD sponsored individual submission; Dan forwarded > the authors to Tim Polk, as this clearly belonged in the security > area. Tim turned down the request due to concerns about > interoperability, and suggested just documenting the experiment > using numbers from the "Private Use" range. The authors submitted > the document to the RFC Editor as independent submission in > December 2007 (not using the Private Use range, but requesting > IANA allocated numbers) . The document has been in Independent > Submission Review phase since then; at least Pasi Eronen and Eric > Rescorla (as then TLS co-chairs) provided input (largely negative) > to the RFC Editorial Board; the document has been updated couple of > times since. > > Protocol Quality > > The extension has not been reviewed by TLS WG or any other IETF > WG. Even a superficial look during the RFC Editor Independent > Submission Review phase discovered things like "two-time pad" > (incorrect use of stream cipher that allowed recovering the XOR of > two plaintexts). > > Note to RFC Editor > > The IESG believes that note #5 from RFC 3932 applies: > > 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. > > Rationale: > > The document introduces several changes to the core cryptographic > parts of TLS: for example, the contents of Certificate and > CertificateVerify handshake messages are changed, and keys that are > currently used in TLS (the premaster secret) are re-used for > another purpose. > > TLS does have extension mechanisms that have been used in the past > to negotiate a different format for the Certificate handshake > message (RFC 5081), and replace the Certificate handshake message > with a different message (RFC 4366). Since these extension > mechanisms can have "subtle (and not-so-subtle) interactions that > may occur in this protocol between new features and existing > features that may result in a significant reduction in overall > security" (to quote text from RFC 4366), the IANA allocation rules > require IETF Consensus (and in certain cases, Standards Action) for > defining such extensions. > > Earlier versions of the draft (when still named draft-urien-badra- > eap-tls-identity-protection) did actually use these extension > mechanisms. By the time the draft was submitted to the RFC Editor, > it had been changed to re-use already allocated numbers with > different contents to get around the IANA rules, and instead uses > bits from the "Cipher Suite" field to negotiate this extension. > > The IANA rules for Cipher Suite numbers allow Specification > Required, since it's relatively simple to define how, for example, > a new encryption algorithm can be used in TLS (without having to > worry about subtle interactions with existing feature). However, > Cipher Suites don't change the overall syntax of Certificate or > CertificateVerify messages, or specify new uses for the premaster > secret key. > > The IESG feels that using this loophole to change core parts of TLS > is not appropriate, and not in line with the TLS architecture. On Dec 9, 2008, at 7:15 AM, Russ Housley wrote: This approach is acceptable to me. Russ At 04:13 AM 12/9/2008, Pasi.Eronen@nokia.com wrote: (IESG Secretary Bcc'd) Hi, During Tuesday breakfast, I mentioned that the RFC Ed Board is planning to ignore the "Do Not Publish" recommendation for this draft. I asked Jim Schaad (who is on the editorial board) about the reasoning behind this; he said this was in the usual "publishing rejected ideas for historical record and/or possible experimentation" category. He did agree that this category does not necessarily need IANA-assigned numbers, and said that if the IESG was OK with publishing this without any IANA assignments (i.e., someone wanting to experiment with this needs to pick numbers from the "private use" range), he would be willing to propose this approach to the rest of the RFC Ed Board. After talking with Tim and the TLS WG chairs (Ekr and Joe Salowey), we agreed that this approach sounds tolerable (as long as the document does not specify any numbers, and is clear about the use of the private use range). He's the first proposal for text (similar to what's in the templin-seal draft): This document does not define any cipher suite numbers. If mutually consenting hosts want to perform experiments with these cipher suites, they need to agree on what values to use from the "Private Use" range (first octet 255; see [RFC5246] Section 12). These values are not to be used for any kind of deployments (i.e., they are not to be shipped in any products). This document therefore has no actions for IANA. Would the rest of the IESG be OK with this approach? (We would also add an IESG note on the front page). If you are, I could contact Jim Schaad. Best regards, Pasi From wwwrun@core3.amsl.com Wed Dec 2 16:36:22 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id nB30Zqov023777 for ; Wed, 2 Dec 2009 16:35:53 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id B39723A6923; Wed, 2 Dec 2009 16:35:59 -0800 (PST) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20091203003441.GE25439@isi.edu> References: <20091203003441.GE25439@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #22001 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 02 Dec 2009 16:35:59 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.ietf.org #22001] AutoReply: Historic Independent Submission: draft-spencer-usefor-son-0f-1036-01.txt -- original netnews Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Historic Independent Submission: draft-spencer-usefor-son-0f-1036-01.txt -- original netnews", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #22001]. Please include the string: [rt.ietf.org #22001] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- IESG, This document was submitted to the RFC Editor to be published as a Historic Independent Submission: draft-spencer-usefor-son-of-1036-01.txt. Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. Four week timeout expires on 30 December 2009. "Son of 1036": News Article Format and Transmission By the early 1990s it had become clear that RFC 1036, the then specification for the Interchange of USENET Messages, was badly in need of repair. This "INTERNET DRAFT to be", though never formally published at that time, was widely circulated and became the de facto standard for implementors of News Servers and User Agents, rapidly acquiring the nickname "Son of 1036". Indeed, under that name, it could fairly be described as the best-known Internet Draft (n)ever published, and it formed the starting point for the recently adopted Proposed Standards for Netnews. It is being published now in order to provide the Historical Background out of which those standards have grown. Present-day implementors should be aware that it is NOT NOW APPROPRIATE for use in current implementations. Please note that we intend to also make the following edits to the document: 1) Add an RFC Editor Note RFC Editor Note: This Historic document has been given a number consistent with the time that most of the work was completed, to put it in context with work done at the time, in spite of not being completed and published until 2009. 2) Modify the Abstract as follows: old: starting point for the recently adopted Proposed Standards for Netnews new: starting point for the recently adopted Proposed Standards for Netnews (RFC5536, RFC5537). 3) Change "Superceded by:" to "Obsoleted by:" in the header. (When it is published, we need to add the back pointers to the database.) 4) Assign it the RFC number 1849, currently unused. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents From wwwrun@core3.amsl.com Wed Dec 2 16:52:18 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id nB30piJk029425 for ; Wed, 2 Dec 2009 16:51:45 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id F3C563A69B8; Wed, 2 Dec 2009 16:51:51 -0800 (PST) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #21917 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 02 Dec 2009 16:51:51 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.ietf.org #21917] Resolved: Experimental RFC to be: draft-hajjeh-tls-identity-protection-09.txt We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Mon Dec 7 12:36:06 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id nB7KYbcG014244 for ; Mon, 7 Dec 2009 12:34:38 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 2C1423A6963; Mon, 7 Dec 2009 12:34:46 -0800 (PST) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20091207203114.GA7699@isi.edu> References: <7CC566635CFE364D87DC5803D4712A6C4C1CAF18DD@XCH-NW-10V.nw.nos.boeing.com> <20091202230018.GB25439@isi.edu> <4B1D09B7.70109@htt-consult.com> <20091207203114.GA7699@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #22099 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Mon, 07 Dec 2009 12:34:47 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.ietf.org #22099] AutoReply: Re: request for XML versions of recent RFCs Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: request for XML versions of recent RFCs", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #22099]. Please include the string: [rt.ietf.org #22099] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Hi Robert, Please note that the RFC Editor does not post Internet-Drafts. We have added the Secretariat on this mail in the hopes that they can help you with the issue you describe below. Thank you. RFC Editor On Mon, Dec 07, 2009 at 08:57:11AM -0500, Robert Moskowitz wrote: > RFC Editor wrote: > >Thomas, > > > >Our apologies for the delay! > > > >The files are attached. However, please note that we were not using > >XML to edit documents on a regular basis when RFC 4423 was published. > >The XML file for RFC 4423 is attached, but it was not used to edit the > >document, so the file is a copy of the XML for the I-D. > > > > Friday I submitted draft-moskowit-rfc4423-bis-00.txt, using the email > robert.moskowitz@icsalabs.com > > I have not received the Submiter Verification key email yet. I sent an > email to ietf-action@ietf.org about this from my icsalabs.com email > address and did receive a comfirmation. Can you look into this? After > the I-D is posted can it please be linked into > http://tools.ietf.org/wg/hip/ so we can start issue tracking on it? I > am trying for today to submit draft-moskowit-rfc5201-bis-00.txt, we will > see how that goes. > > >For the rest of the documents listed, please note that XML was used > >throughout the AUTH48 processs, but there are small discrepancies > >between the XML and the published text file (e.g., line breaks, page > >breaks, and anything else that was caught after the XML file was > >converted to .nroff) that occur post-xml2rfc. > > > >Please let us know if you have any questions. > > > >Thank you. > > > >RFC Editor/sg > > > > > >On Wed, Dec 02, 2009 at 02:24:28PM -0800, Henderson, Thomas R wrote: > > > >>Dear RFC Editor, > >> > >>I am resending the below request in case you may not have received it. > >>Can you provide these XML documents? > >> > >>- Tom > >> > >> > >>>-----Original Message----- > >>>From: Henderson, Thomas R > >>>Sent: Tuesday, November 17, 2009 8:41 PM > >>>To: RFC Editor > >>>Cc: 'Petri Jokela'; Gonzalo.Camarillo@ericsson.com; 'Robert > >>>Moskowitz'; Julien Laganier; 'Pekka Nikander'; David Ward > >>>Subject: request for XML versions of recent RFCs > >>> > >>>Dear RFC Editor, > >>> > >>>The various authors of the HIP RFCs would like to obtain > >>>copies of the most recent XML corresponding to the published > >>>RFCs. We believe that the RFC Editor may have the most > >>>recent copies. Could you please send them to me or point me > >>>to where they may be downloaded from? (I could not find this > >>>on the rfc editor page) > >>> > >>>Thanks, > >>>Tom Henderson > >>> > >>>RFC 4423 Host Identity Protocol Architecture > >>>RFC 5201 Host Identity Protocol > >>>RFC 5202 Using the Encapsulating Security Payload Transport > >>>Format with HIP > >>>RFC 5203 HIP Registration Extension > >>>RFC 5204 HIP Rendezvous Extensions > >>>RFC 5205 HIP Domain Name System extensions > >>>RFC 5206 HIP Mobility and Multihoming > >>> > >>> From wwwrun@core3.amsl.com Tue Dec 8 10:00:53 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id nB8I0aSP015214 for ; Tue, 8 Dec 2009 10:00:37 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 2FA143A6A3A; Tue, 8 Dec 2009 10:00:45 -0800 (PST) From: "Stephanie via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #22045 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: smccammon@amsl.com To: rfc-editor@rfc-editor.org, rgm@htt-consult.com, robert.moskowitz@icsalabs.com MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 08 Dec 2009 10:00:46 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.ietf.org #22045] Resolved: Submitted draft-moskowitz-rfc4423-bis-00, no authentication email We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Tue Dec 8 13:53:20 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id nB8Lqj2e018352 for ; Tue, 8 Dec 2009 13:52:46 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 8146D3A67EF; Tue, 8 Dec 2009 13:52:55 -0800 (PST) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20091208215144.GA12533@isi.edu> References: <20091208215144.GA12533@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #22128 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 08 Dec 2009 13:52:55 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.ietf.org #22128] AutoReply: Informational Independent Submissions: draft-dolmatov-cryotocom-gost341194-06, draft-dolmatov-cryptocom-gost2814789-06, draft-dolmatov-cryptocom-gost34102001-07 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Informational Independent Submissions: draft-dolmatov-cryotocom-gost341194-06, draft-dolmatov-cryptocom-gost2814789-06, draft-dolmatov-cryptocom-gost34102001-07", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #22128]. Please include the string: [rt.ietf.org #22128] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- IESG, These documents were submitted to the RFC Editor to be published as Informational Independent Submissions: draft-dolmatov-cryptocom-gost34102001-07.txt draft-dolmatov-cryptocom-gost341194-06.txt draft-dolmatov-cryptocom-gost2814789-06.txt Please let us know if these documents conflict with the IETF standards process or other work being done in the IETF community. Five week timeout expires on 12 January 2010. (Note that we included an additional week for review because of the upcoming holidays.) I-D: draft-dolmatov-cryptocom-gost34102001-07 Title: GOST R 34.10-2001 digital signature algorithm Abstract: This document is intended to be a source of information about the Russian Federal standard for for electronic digital signature generation and verification processes GOST R 34.10-2001 [GOST3410], which is one of the official standards in the cryptography used in Russian algorithms (GOST algorithms). Recently, Russian cryptography started to be used in applications intended to work with the OpenSSL cryptographic library. Therefore, this document has been created as information for users of Russian cryptography. I-D: draft-dolmatov-cryptocom-gost341194-06 Title: GOST R 34.11-94 Hash function algorithm Abstract: This document is intended to be a source of information about the Russian Federal standard for hash function GOST R 34.11-94 [GOST3411] which is one of the official standards in the cryptography, used in Russian algorithms (GOST algorithms). Recently, Russian cryptography started to be used in applications intended to work with the OpenSSL cryptographic library. Therefore, this document has been created as information for users of Russian cryptography. I-D: draft-dolmatov-cryptocom-gost2814789-06 Title: GOST 28147-89 encryption, decryption and MAC algorithms Abstrac: This document is intended to be a source of information about the Russian Federal standard for electronic encryption, decryption, and MAC algorithms (GOST 28147-89) [GOST28147], which is one of the official standards in the cryptography used in Russian algorithms (GOST algorithms). Recently, Russian cryptography started to be used in applications intended to work with the OpenSSL cryptographic library. Therefore, this document has been created as information for users of Russian cryptography. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents From wwwrun@core3.amsl.com Thu Dec 17 15:50:01 2009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id nBHNnRrL029342 for ; Thu, 17 Dec 2009 15:49:28 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id ED56F3A69E6; Thu, 17 Dec 2009 15:49:40 -0800 (PST) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #22128 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 17 Dec 2009 15:49:40 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.ietf.org #22128] Resolved: Informational Independent Submissions: draft-dolmatov-cryotocom-gost341194-06, draft-dolmatov-cryptocom-gost2814789-06, draft-dolmatov-cryptocom-gost34102001-07 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Mon Jan 4 10:32:37 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id o04IVOjG005687 for ; Mon, 4 Jan 2010 10:31:25 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id BC4B23A68FE; Mon, 4 Jan 2010 10:31:24 -0800 (PST) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #21910 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Mon, 04 Jan 2010 10:31:24 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.ietf.org #21910] Resolved: Experimental Independent Submission: draft-zeilenga-ldap-txn-15.txt We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Mon Jan 4 10:33:35 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id o04IWhYX006467 for ; Mon, 4 Jan 2010 10:32:44 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id CE1E13A6898; Mon, 4 Jan 2010 10:32:43 -0800 (PST) From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #22001 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Mon, 04 Jan 2010 10:32:43 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.ietf.org #22001] Resolved: Historic Independent Submission: draft-spencer-usefor-son-0f-1036-01.txt -- original netnews We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Wed Jan 6 21:38:54 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id o075cSW7015226 for ; Wed, 6 Jan 2010 21:38:29 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id D068028C0FC; Wed, 6 Jan 2010 21:38:29 -0800 (PST) From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100107053726.GA12404@isi.edu> References: <8C9178D6-218C-4277-8D00-9E7F8E86B445@ISI.EDU> <20100107053726.GA12404@isi.edu> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #22856 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 06 Jan 2010 21:38:29 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: wwwrun@core3.amsl.com Subject: [rt.ietf.org #22856] AutoReply: Old RFCs online (RFC Online Project) Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Old RFCs online (RFC Online Project)", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #22856]. Please include the string: [rt.ietf.org #22856] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings! Awhile ago, Russ had indicated that there may be some manual processing that the Secretariat needs to do for the older documents. Please note that the list of RFCs below is now available online. Thanks! Sandy 74 112 119 165 183 211 216 254 296 304 360 403 475 522 535 576 577 578 579 581 586 592 594 600 645 647 661 671 679 694 696 712 714 > >> > > > >Hi Cindy, > > > >During a meeting at IETF 72, Russ asked that we notify the IESG > >Secretariat when we are putting RFCs online where the RFC number is > >fewer than 4 digits (e.g., rfc5.txt, rfc325.pdf). I believe he > >said the secretariat has to do some manual updates to the site > >because the scripts(?) were designed to handle 4 digit RFC numbers. > > > >Let me know if you have any additional questions. If so, I can get > >further clarification from Russ. > > > >Thanks! > > > >Sandy > > > > > >> > >>-------- Original Message -------- > >>Subject: [rt.amsl.com #11237] Old RFCs online (RFC Online Project) > >>Date: Mon, 27 Oct 2008 14:56:28 -0700 > >>From: Cindy Morgan via RT > >>Reply-To: iesg-secretary@iesg.org > >>To: alba@ISI.EDU > >>References: <490261BF.70200@isi.edu> > >> > >>Hi Alba, > >> > >>We've received a number of messages similar to the one below over the > >>last few days, and we're wondering what action you're looking for the > >>IETF secretariat to take. Can you please clarify? > >> > >>Best regards, > >>Cindy > >> > >>On Fri Oct 24 17:00:28 2008, alba@ISI.EDU wrote: > >>>Please note that the following PDF files of RFCs have been made > >>>available (RFC Online Project): > >>>rfc165.pdf > >>>rfc169.pdf > >>>rfc183.pdf > >>>rfc199.pdf > >>>rfc206.pdf > >>>rfc211.pdf > >>>rfc216.pdf > >>>rfc296.pdf > >>>rfc304.pdf > >>>rfc320.pdf > >>>Thank you. > >>>RFC Editor/ar > >> > >> > > > From wwwrun@core3.amsl.com Tue Jan 26 09:17:05 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.4 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 12EEEE06A8 for ; Tue, 26 Jan 2010 09:17:05 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRCxevijMKXf for ; Tue, 26 Jan 2010 09:17:04 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id E7F35E06A4 for ; Tue, 26 Jan 2010 09:17:04 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id A48603A6892; Tue, 26 Jan 2010 09:16:53 -0800 (PST) Subject: [rt.ietf.org #23312] AutoReply: Re: Document Action: 'Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)' to Experimental RFC From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100126171702.GB15008@rfc-editor.org> References: <20100125142856.C30563A68C6@core3.amsl.com> <20100126171702.GB15008@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23312 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 26 Jan 2010 09:16:53 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)' to Experimental RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #23312]. Please include the string: [rt.ietf.org #23312] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Mon, Jan 25, 2010 at 06:28:56AM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'Binding Extensions to Web Distributed Authoring and Versioning > (WebDAV) ' > as an Experimental RFC > > This document has been reviewed in the IETF but is not the product of an > IETF Working Group. > > The IESG contact person is Alexey Melnikov. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-webdav-bind-27.txt > > Technical Summary > > The WebDAV BIND extensions adds the ability for a client to create > different "bindings" between URIs and resources on a WebDAV server. This > is similar to file system "hard linking" or "aliases". Clients can also > discover bindings on the server even in cases where they cannot create > them. Additionally this specification clarifies some aspects of RFC3253 > (Delta-V) that rely on the BIND model. > > Working Group Summary > > Discussion has taken place on the WebDAV mailing list over a long > period of time as the document has evolved. There have been three > "informal" last calls on the document during this time. > However this document is not a WG document, as WebDAV has concluded > since. > > Document Quality > > Several implementations of this specification already exist (Apache > Jackrabbit, Apache Slide, SAP Netweaver KM). Additionally Java Content > Repository (JCR) 2.0 ('shareable nodes' feature) and Content Management > Interoperability Services (CMIS) ('multifiling' feature) specs both > specify identical concepts which need BIND in order to be exposed via > WebDAV. Discussion of how this extension might be used in CalDAV and > CardDAV to implement "shared" calendars or address books is also on-going. From wwwrun@core3.amsl.com Tue Jan 26 09:17:16 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.4 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 63F1DE06A8 for ; Tue, 26 Jan 2010 09:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QorM0xH6Hyz for ; Tue, 26 Jan 2010 09:17:16 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 469E8E06A4 for ; Tue, 26 Jan 2010 09:17:16 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 2005B3A688C; Tue, 26 Jan 2010 09:17:04 -0800 (PST) Subject: [rt.ietf.org #23313] AutoReply: Re: Document Action: 'Requirements for a Location-by-Reference Mechanism' to Informational RFC From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100126171713.GC15008@rfc-editor.org> References: <20100125143143.DEEF83A69FA@core3.amsl.com> <20100126171713.GC15008@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23313 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 26 Jan 2010 09:17:05 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'Requirements for a Location-by-Reference Mechanism' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #23313]. Please include the string: [rt.ietf.org #23313] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Mon, Jan 25, 2010 at 06:31:43AM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'Requirements for a Location-by-Reference Mechanism ' > as an Informational RFC > > > This document is the product of the Geographic Location/Privacy Working Group. > > The IESG contact persons are Cullen Jennings and Robert Sparks. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-lbyr-requirements-09.txt > > Technical Summary: > > This document defines terminology and describes requirements for the > use of Location-by-Reference, a means of indirectly providing location > information within the GEOPRIV architecture defined in RFC 3693. The > document describes the use of location URIs as a means of providing > this indirection. The document provides requirements that pay > particular attention to privacy and security. > > Working Group Summary: > > This document represents the strong consensus of the GEOPRIV working > group. > > Document Quality: > > This requirements document is the product of design team work in the > GEOPRIV working group. It has been thoroughly reviewed by GEOPRIV > participants. > > Personnel > > The document shepherd for this document is Alissa Cooper. From wwwrun@core3.amsl.com Tue Jan 26 09:17:33 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.4 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 050D3E06AB for ; Tue, 26 Jan 2010 09:17:33 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCOhj0RldhAS for ; Tue, 26 Jan 2010 09:17:32 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id E15FBE06A4 for ; Tue, 26 Jan 2010 09:17:32 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id B9FC93A68AF; Tue, 26 Jan 2010 09:17:21 -0800 (PST) Subject: [rt.ietf.org #23314] AutoReply: Re: CORRECTED Document Action: 'Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks' to Informational RFC From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100126171731.GD15008@rfc-editor.org> References: <20100125170621.20EFC3A67E7@core3.amsl.com> <20100126171731.GD15008@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23314 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 26 Jan 2010 09:17:21 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: CORRECTED Document Action: 'Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #23314]. Please include the string: [rt.ietf.org #23314] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Mon, Jan 25, 2010 at 09:06:21AM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering > Networks ' > as an Informational > RFC > > > This document is the product of the Common Control and Measurement Plane > Working Group. > > The IESG contact persons are Adrian Farrel and Ross Callon. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-graceful-shutdown-13.txt > Technical Summary > > MPLS-TE Graceful Shutdown is a method for explicitly notifying > the nodes in a Traffic Engineering (TE) enabled network that the > TE capability on a link or on an entire Label Switching Router > (LSR) is going to be disabled. MPLS-TE graceful shutdown > mechanisms are tailored toward addressing planned outage in the > network. > > This document provides requirements and protocol mechanisms to > reduce/eliminate traffic disruption in the event of a planned > shutdown of a network resource. These operations are equally > applicable to both MPLS and its Generalized MPLS (GMPLS) > extensions. > > This document explains usage of existing protocol mechanisms to > support a "Graceful Shutdown" operation. No new protocol mechanisms > are defined > > Working Group Summary > > The document was significantly revised to be in line with > draft-ietf-mpls-gmpls-lsp-reroute. Much of the WG discussion focused > on this. Once alignment was agreed upon, there was no significant > disagreement. > > Document Quality > > There are no known implementations or planned implementations of this > work. > > Personnel > > Lou Berger (lberger@labn.net) is the Document Shepherd. > > Adrian Farrel (adrian.farrel@huawei.com) is the > Responsible Area Director. From wwwrun@core3.amsl.com Tue Jan 26 09:17:48 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.4 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id DB49FE06AA for ; Tue, 26 Jan 2010 09:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4+yI3YCWrsF for ; Tue, 26 Jan 2010 09:17:48 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id BF966E06A4 for ; Tue, 26 Jan 2010 09:17:48 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 7A4663A68CE; Tue, 26 Jan 2010 09:17:37 -0800 (PST) Subject: [rt.ietf.org #23315] AutoReply: Re: Protocol Action: 'SCTP based TML (Transport Mapping Layer) for ForCES protocol' to Proposed Standard From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100126171746.GE15008@rfc-editor.org> References: <20100125182929.8206328C0FE@core3.amsl.com> <20100126171746.GE15008@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23315 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 26 Jan 2010 09:17:37 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'SCTP based TML (Transport Mapping Layer) for ForCES protocol' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #23315]. Please include the string: [rt.ietf.org #23315] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Mon, Jan 25, 2010 at 10:29:29AM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'SCTP based TML (Transport Mapping Layer) for ForCES protocol ' > as a Proposed Standard > > > This document is the product of the Forwarding and Control Element Separation Working Group. > > The IESG contact persons are Ross Callon and Adrian Farrel. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-forces-sctptml-08.txt > > Technical Summary > > This document defines the SCTP based TML (Transport Mapping Layer) > for the ForCES protocol. It explains the rationale for choosing the > SCTP (Stream Control Transmission Protocol) [RFC4960] and also > describes how this TML addresses all the requirements described in > [RFC3654] and the ForCES protocol draft . > > Working Group Summary > > There is strong working group consensus behind this document. > It is an effort of several years work. > > Document Quality > > The document has been well reviewed. An interop in July 2009 > between 3 different implementations by WG participant utilizing > draft version 4 was successful. In addition, there are two > different extensions to public domain traffic sniffers (ethereal > and tcpdump) by 2 other WG participants. > > Personnel > > Joel Halpern is the Document Shepherd. Ross Callon is the > responsible AD. From wwwrun@core3.amsl.com Tue Jan 26 09:17:57 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-104.0 required=5.0 tests=AWL,BAYES_00, HELO_MISMATCH_ORG,HOST_MISMATCH_COM,RCVD_IN_DNSWL_MED,USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 331C7E06AA for ; Tue, 26 Jan 2010 09:17:57 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuFNV3ub-9VG for ; Tue, 26 Jan 2010 09:17:57 -0800 (PST) Received: from mail.ietf.org (core3.amsl.com [64.170.98.32]) by rfc-editor.org (Postfix) with ESMTP id 197F0E06A4 for ; Tue, 26 Jan 2010 09:17:57 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id E3E433A68AF; Tue, 26 Jan 2010 09:17:45 -0800 (PST) Subject: [rt.ietf.org #23316] AutoReply: Re: Protocol Action: 'ESMTP and LMTP Transmission Types Registration' to Draft Standard From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100126171755.GF15008@rfc-editor.org> References: <20100125203115.582BC3A68FA@core3.amsl.com> <20100126171755.GF15008@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23316 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 26 Jan 2010 09:17:45 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'ESMTP and LMTP Transmission Types Registration' to Draft Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #23316]. Please include the string: [rt.ietf.org #23316] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Mon, Jan 25, 2010 at 12:31:15PM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'ESMTP and LMTP Transmission Types Registration ' > RFC 3848 as a Draft Standard > > This document has been reviewed in the IETF but is not the product of an > IETF Working Group. > > The IESG contact person is Alexey Melnikov. > > A URL of this RFC is: > http://www.ietf.org/rfc/rfc3848.txt > > Technical Summary > > This document registers seven new mail transmission types (ESMTPA, > ESMTPS, ESMTPSA, LMTP, LMTPA, LMTPS, LMTPSA) for use in the "with" > clause of a Received header in an Internet message. > > Working Group Summary > > This is not a working group document. > Publication of the RFC 3848 was non controversial. > > Document Quality > > There are multiple implementations (both parsers and generators) > of the protocol, please see the implementation report. > > Personnel > > Alexey Melnikov is the responsible Area Director. This document > has no shepherd. From wwwrun@core3.amsl.com Tue Jan 26 09:18:05 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.6 required=5.0 tests=BAYES_00,USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id B8727E06AA for ; Tue, 26 Jan 2010 09:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQQF54tgFgKZ for ; Tue, 26 Jan 2010 09:18:05 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 9A199E06A4 for ; Tue, 26 Jan 2010 09:18:05 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 734753A68D1; Tue, 26 Jan 2010 09:17:54 -0800 (PST) Subject: [rt.ietf.org #23317] AutoReply: Re: Document Action: 'Extensible Authentication Protocol (EAP) Early Authentication Problem Statement' to Informational RFC From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100126171803.GG15008@rfc-editor.org> References: <20100125203327.3CBEC3A68A0@core3.amsl.com> <20100126171803.GG15008@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23317 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 26 Jan 2010 09:17:54 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'Extensible Authentication Protocol (EAP) Early Authentication Problem Statement' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #23317]. Please include the string: [rt.ietf.org #23317] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Mon, Jan 25, 2010 at 12:33:27PM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'Extensible Authentication Protocol (EAP) Early Authentication Problem > Statement ' > as an Informational RFC > > > This document is the product of the Handover Keying Working Group. > > The IESG contact persons are Tim Polk and Pasi Eronen. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-hokey-preauth-ps-12.txt > > Technical Summary > > Extensible Authentication Protocol early authentication may be > defined as the use of EAP by a mobile device to establish > authenticated keying material on a target attachment point prior to > its arrival. This draft discusses the EAP early authentication > problem in detail. > > Working Group Summary > > The Working Group experienced major controversy over the inclusion > of what was eventually termed the "Authenticated Anticipatory Keying > Usage Model" within the document. The controversy between the new > model and "EAP preauthentication" was resolved by reserving the > latter term for a very specific architectural arrangement and creating > > > > a distinct name for the new model. This change was also reflected in > > > a new document title. > > Document Quality > > The document is a problem statement and as such, lays the groundwork > for development of solutions to the identified problems. > > Personnel > > Tina Tsou is the Document Shepherd for this document. Tim Polk is > the Responsible Area Director. From wwwrun@core3.amsl.com Tue Jan 26 09:18:22 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.3 required=5.0 tests=AWL,BAYES_00, J_CHICKENPOX_13,USER_IN_WHITELIST autolearn=no version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id B85B7E06AA for ; Tue, 26 Jan 2010 09:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXDsbaeWLc1J for ; Tue, 26 Jan 2010 09:18:22 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 9DABAE06A4 for ; Tue, 26 Jan 2010 09:18:22 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id A764F3A6933; Tue, 26 Jan 2010 09:18:08 -0800 (PST) Subject: [rt.ietf.org #23318] AutoReply: Re: Document Action: 'Requirements for supporting Customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN' to Informational RFC From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100126171811.GH15008@rfc-editor.org> References: <20100125203439.AC5F43A6926@core3.amsl.com> <20100126171811.GH15008@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23318 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 26 Jan 2010 09:18:08 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'Requirements for supporting Customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #23318]. Please include the string: [rt.ietf.org #23318] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Mon, Jan 25, 2010 at 12:34:39PM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'Requirements for supporting Customer RSVP and RSVP-TE over a BGP/MPLS > IP-VPN ' > as an Informational RFC > > > This document is the product of the Layer 3 Virtual Private Networks Working Group. > > The IESG contact persons are Ross Callon and Adrian Farrel. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-e2e-rsvp-te-reqts-05.txt > > Technical Summary > > This informational document describes service provider requirements > for supporting a customer RSVP and RSVP-TE over a BGP/MPLS-IP L3VPN. > For example, this may be used to run triple play services through > BGP/MPLS IP-VPNs. Some Service Providers will deploy services that > request QoS guarantees from a local CE to a remote CE across the > network. As a result, the application (e.g., voice, video, > bandwidth-guaranteed data pipe, etc.) requirements for an end-to- > end QOS and reserving an adequate bandwidth continue to increase. > > Working Group Summary > > There were no objections during the WG Last Call on the document, > and the utility of this specification is both obvious and intuitive > (see PROTO writeup by Danny McPherson in the ID Tracker). > > Document Quality > > As a requirements document, it is not subject to be implemented. The > document was updated in response to IETF last call comments. > > Personnel > > Danny McPherson is the Document Shepherd for this document. Ross > Callon is the Responsible Area Director. From wwwrun@core3.amsl.com Tue Jan 26 09:18:27 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.4 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 0CABEE06AA for ; Tue, 26 Jan 2010 09:18:27 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdqTDPmWR0PE for ; Tue, 26 Jan 2010 09:18:26 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id E778CE06A4 for ; Tue, 26 Jan 2010 09:18:26 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id AF53C3A68B3; Tue, 26 Jan 2010 09:18:15 -0800 (PST) Subject: [rt.ietf.org #23319] AutoReply: Re: Document Action: 'Additional Hash Algorithms for HTTP Instance Digests' to Informational RFC From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100126171825.GI15008@rfc-editor.org> References: <20100125203631.959FF3A6926@core3.amsl.com> <20100126171825.GI15008@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23319 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 26 Jan 2010 09:18:15 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'Additional Hash Algorithms for HTTP Instance Digests' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #23319]. Please include the string: [rt.ietf.org #23319] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Mon, Jan 25, 2010 at 12:36:31PM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'Additional Hash Algorithms for HTTP Instance Digests ' > as an Informational RFC > > This document has been reviewed in the IETF but is not the product of an > IETF Working Group. > > The IESG contact person is Lisa Dusseault. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bryan-http-digest-algorithm-values-update-04.txt > > Technical Summary > > The IANA registry named "Hypertext Transfer Protocol (HTTP) Digest > Algorithm Values" defines values for digest algorithms used by > Instance Digests in HTTP. Instance Digests in HTTP provide a digest, > also known as a checksum or hash, of an entire representation of the > current state of a resource. This draft adds new values to the > registry and updates previous values. > > > Working Group Summary > > This is not a WG document, but was reviewed in the HTTPBIS WG. > > Document Quality > > This document updates IANA/registration procedures rather than > affecting an implementable protocol. > > Personnel > > Lisa Dusseault is the sponsor for this document. From wwwrun@core3.amsl.com Tue Jan 26 09:18:37 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 3EEC1E06AA for ; Tue, 26 Jan 2010 09:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r334qZb+XjhI for ; Tue, 26 Jan 2010 09:18:37 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 24B24E06A4 for ; Tue, 26 Jan 2010 09:18:37 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id E1E0D3A68CD; Tue, 26 Jan 2010 09:18:25 -0800 (PST) Subject: [rt.ietf.org #23321] AutoReply: Re: Document Action: 'Link Relation Types for Simple Version Navigation between Web Resources' to Informational RFC From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100126171834.GJ15008@rfc-editor.org> References: <20100125203846.7293D3A68A4@core3.amsl.com> <20100126171834.GJ15008@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23321 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 26 Jan 2010 09:18:25 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'Link Relation Types for Simple Version Navigation between Web Resources' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #23321]. Please include the string: [rt.ietf.org #23321] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Mon, Jan 25, 2010 at 12:38:46PM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'Link Relation Types for Simple Version Navigation between Web > Resources ' > as an Informational RFC > > This document has been reviewed in the IETF but is not the product of an > IETF Working Group. > > The IESG contact person is Lisa Dusseault. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-brown-versioning-link-relations-07.txt > > Technical Summary > > This specification defines Atom link relations for navigation between > a resource and its versions. > > Working Group Summary > > This is not a working group document. > > Document Quality > > This document mostly registers values. It is a straightforward > proposal to adapt an existing model (WebDAV versioning and its > relationships between resources) to the link relation approach > to describing relationships. Given how straightforward this is, > the document has received sufficient review. > > Personnel > > Lisa Dusseault is the sponsor of this document. > the IESG is responsible for approving the link relations > registrations by approving this document. From wwwrun@core3.amsl.com Tue Jan 26 09:20:03 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id E1ABFE06AA for ; Tue, 26 Jan 2010 09:20:03 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfZ57rS1Rbyx for ; Tue, 26 Jan 2010 09:20:03 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id C8D96E06A4 for ; Tue, 26 Jan 2010 09:20:03 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 9953C3A686C; Tue, 26 Jan 2010 09:19:52 -0800 (PST) Subject: [rt.ietf.org #23312] Resolved: Re: Document Action: 'Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)' to Experimental RFC From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23312 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 26 Jan 2010 09:19:52 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Tue Jan 26 09:20:49 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id D870CE06AA for ; Tue, 26 Jan 2010 09:20:49 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DgZpMOQxdRm for ; Tue, 26 Jan 2010 09:20:49 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id C22FEE06A4 for ; Tue, 26 Jan 2010 09:20:49 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 9037F3A6907; Tue, 26 Jan 2010 09:20:38 -0800 (PST) Subject: [rt.ietf.org #23313] Resolved: Re: Document Action: 'Requirements for a Location-by-Reference Mechanism' to Informational RFC From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23313 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 26 Jan 2010 09:20:38 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Tue Jan 26 09:21:31 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 406AEE06CC for ; Tue, 26 Jan 2010 09:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jG85MVchrMLZ for ; Tue, 26 Jan 2010 09:21:31 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 2C2E0E06B6 for ; Tue, 26 Jan 2010 09:21:31 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id F3CA33A694F; Tue, 26 Jan 2010 09:21:19 -0800 (PST) Subject: [rt.ietf.org #23318] Resolved: Re: Document Action: 'Requirements for supporting Customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN' to Informational RFC From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23318 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 26 Jan 2010 09:21:19 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Tue Jan 26 09:22:17 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.6 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id D3D65E06AA for ; Tue, 26 Jan 2010 09:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNBknBO2v5Xr for ; Tue, 26 Jan 2010 09:22:17 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id BEABBE06A4 for ; Tue, 26 Jan 2010 09:22:17 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 8FF2A3A696F; Tue, 26 Jan 2010 09:22:06 -0800 (PST) Subject: [rt.ietf.org #23315] Resolved: Re: Protocol Action: 'SCTP based TML (Transport Mapping Layer) for ForCES protocol' to Proposed Standard From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23315 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 26 Jan 2010 09:22:06 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Tue Jan 26 09:23:01 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.6 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 3B420E06AA for ; Tue, 26 Jan 2010 09:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyBk367MT23o for ; Tue, 26 Jan 2010 09:23:01 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id D7595E06A4 for ; Tue, 26 Jan 2010 09:23:00 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id A4B523A694F; Tue, 26 Jan 2010 09:22:49 -0800 (PST) Subject: [rt.ietf.org #23317] Resolved: Re: Document Action: 'Extensible Authentication Protocol (EAP) Early Authentication Problem Statement' to Informational RFC From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23317 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 26 Jan 2010 09:22:49 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Tue Jan 26 09:26:51 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.6 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 4620CE06AA for ; Tue, 26 Jan 2010 09:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bozAAcNX6s6 for ; Tue, 26 Jan 2010 09:26:51 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 2A3EDE06A4 for ; Tue, 26 Jan 2010 09:26:51 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id EA2D33A688E; Tue, 26 Jan 2010 09:26:39 -0800 (PST) Subject: [rt.ietf.org #23321] Resolved: Re: Document Action: 'Link Relation Types for Simple Version Navigation between Web Resources' to Informational RFC From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23321 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 26 Jan 2010 09:26:39 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Tue Jan 26 09:27:33 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.6 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 599A1E06AA for ; Tue, 26 Jan 2010 09:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-XbFeuLxhME for ; Tue, 26 Jan 2010 09:27:33 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 448BEE06A4 for ; Tue, 26 Jan 2010 09:27:33 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id DE05C3A6817; Tue, 26 Jan 2010 09:27:21 -0800 (PST) Subject: [rt.ietf.org #23319] Resolved: Re: Document Action: 'Additional Hash Algorithms for HTTP Instance Digests' to Informational RFC From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23319 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 26 Jan 2010 09:27:21 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Tue Jan 26 09:28:44 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.6 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id EB092E06AA for ; Tue, 26 Jan 2010 09:28:44 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-C0ruZKtfEO for ; Tue, 26 Jan 2010 09:28:44 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id D5040E06A4 for ; Tue, 26 Jan 2010 09:28:44 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id A6D753A6809; Tue, 26 Jan 2010 09:28:33 -0800 (PST) Subject: [rt.ietf.org #23316] Resolved: Re: Protocol Action: 'ESMTP and LMTP Transmission Types Registration' to Draft Standard From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23316 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 26 Jan 2010 09:28:33 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Tue Jan 26 09:29:47 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.6 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id F38DFE06AA for ; Tue, 26 Jan 2010 09:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcEryfrrqq1h for ; Tue, 26 Jan 2010 09:29:46 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id DE04AE06A4 for ; Tue, 26 Jan 2010 09:29:46 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id ADBFA3A67DB; Tue, 26 Jan 2010 09:29:35 -0800 (PST) Subject: [rt.ietf.org #23314] Resolved: Re: CORRECTED Document Action: 'Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks' to Informational RFC From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23314 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 26 Jan 2010 09:29:35 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Wed Jan 27 11:34:51 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.6 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 7C0E6E06A8 for ; Wed, 27 Jan 2010 11:34:51 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCuNnNI361Fc for ; Wed, 27 Jan 2010 11:34:51 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 5BF6DE0697 for ; Wed, 27 Jan 2010 11:34:51 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id B3ED33A6951; Wed, 27 Jan 2010 11:34:35 -0800 (PST) Subject: [rt.ietf.org #23356] AutoReply: Re: Protocol Action: 'Extending ICMP for Interface and Next-hop Identification' to Proposed Standard From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100127193441.GA5352@rfc-editor.org> References: <20100126173338.153233A681B@core3.amsl.com> <20100127193441.GA5352@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23356 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 27 Jan 2010 11:34:35 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Extending ICMP for Interface and Next-hop Identification' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #23356]. Please include the string: [rt.ietf.org #23356] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- received. On Tue, Jan 26, 2010 at 09:33:38AM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'Extending ICMP for Interface and Next-hop Identification ' > as a Proposed Standard > > This document has been reviewed in the IETF but is not the product of an > IETF Working Group. > > The IESG contact person is Jari Arkko. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-atlas-icmp-unnumbered-09.txt > > Technical Summary > > This draft extends ICMP to provide additional diagnostic > information regarding incoming and outgoing interfaces. > > Working Group Summary > > This draft has been discussed in the Internet Area mailing > list and meetings; considerable discussion happened on the > topic of including next-hop information. The document is > an AD sponsored submission, however. > > In January 2009, a late IPR declaration forced the draft to > go back to the WG. It has now returned after no one objected > in the new WGLC (after the new IPR license declaration was > posted). > > In the fall of 2009, the document went through another round > of WG reviews and an IETF last call was requested, as the > document had been largely rewritten in the summer to address > IESG review comments from the previous round. > > Document Quality > > The document has been extensively reviewed and discussed. > > Personnel > > There is no document shepherd. The responsible AD is > Jari Arkko. From wwwrun@core3.amsl.com Wed Jan 27 11:35:48 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.6 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id CC6B0E06AF for ; Wed, 27 Jan 2010 11:35:48 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d952FGnlAyrO for ; Wed, 27 Jan 2010 11:35:48 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id B0D29E0697 for ; Wed, 27 Jan 2010 11:35:48 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 2BE823A6930; Wed, 27 Jan 2010 11:35:32 -0800 (PST) Subject: [rt.ietf.org #23357] AutoReply: Re: Protocol Action: 'Wrapped ESP for Traffic Visibility' to Proposed Standard From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100127193547.GB5352@rfc-editor.org> References: <20100126202922.527BE3A68DA@core3.amsl.com> <20100127193547.GB5352@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23357 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 27 Jan 2010 11:35:33 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Wrapped ESP for Traffic Visibility' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #23357]. Please include the string: [rt.ietf.org #23357] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Tue, Jan 26, 2010 at 12:29:22PM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'Wrapped ESP for Traffic Visibility ' > as a Proposed Standard > > > This document is the product of the IP Security Maintenance and Extensions Working Group. > > The IESG contact persons are Pasi Eronen and Tim Polk. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-traffic-visibility-12.txt > > Technical Summary > > This document describes the Wrapped Encapsulating Security Payload > (WESP) protocol, which is based on the Encapsulating Security > Payload (ESP) protocol and is designed to allow intermediate > devices to ascertain if ESP with null encryption is being employed > and if so, inspect the IPsec packets for network monitoring and > access control functions. The mechanism described in this document > can be used to easily disambiguate ESP-NULL from encrypted ESP > packets, without compromising on the security provided by ESP. > > Working Group Summary > > Early on there was prolonged WG discussion about the relative > merits of the Wrapped ESP solution for identifying ESP-null > traffic, compared to heuristic methods for traffic > inspection. Eventually the WG reached consensus on the usefulness > of having both solutions published, with the heuristics solution > targeted for the interim period until WESP is widely deployed. This > consensus is documented in both protocol documents. > > IESG review also lead to clarifying the protocol's extensibility > model: if there is consensus in the future to extend the protocol, > those extensions need a new WESP version number, and have to be > negotiated by the endpoints. This simplified the protocol by, > for example, keeping the ICV coverage unchanged from ESP. > > Document Quality > > Currently, there are no known implementations. However, a number of > vendors have expressed interest and supported this activity. > > Personnel > > The document shepherd is Yaron Sheffer, and the responsible > area director is Pasi Eronen. From wwwrun@core3.amsl.com Wed Jan 27 11:36:19 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.6 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 3E45CE06A8 for ; Wed, 27 Jan 2010 11:36:19 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epYqrYwI-w9m for ; Wed, 27 Jan 2010 11:36:19 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 243F2E0697 for ; Wed, 27 Jan 2010 11:36:19 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 92EE33A698A; Wed, 27 Jan 2010 11:36:03 -0800 (PST) Subject: [rt.ietf.org #23358] AutoReply: Re: Protocol Action: 'An Extension to Session Initiation Protocol From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100127193617.GC5352@rfc-editor.org> References: <20100127170525.634903A6AB2@core3.amsl.com> <20100127193617.GC5352@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23358 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 27 Jan 2010 11:36:03 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'An Extension to Session Initiation Protocol", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #23358]. Please include the string: [rt.ietf.org #23358] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Wed, Jan 27, 2010 at 09:05:25AM -0800, iesg-secretary wrote: > (SIP) Events for Conditional Event Notification' to Proposed Standard > > The IESG has approved the following document: > > - 'An Extension to Session Initiation Protocol (SIP) Events > for Conditional Event Notification ' > as a Proposed Standard > > > This document is the product of the Session Initiation Protocol Core > Working Group. > > The IESG contact persons are Robert Sparks and Cullen Jennings. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-subnot-etags-04.txt > > Technical Summary > > The Session Initiation Protocol (SIP) events framework enables > receiving asynchronous notification of various events from other SIP > user agents. This framework defines the procedures for creating, > refreshing and terminating subscriptions, as well as fetching and > periodic polling of resource state. These SIP Events Framework > procedures have a serious deficiency in that they provide no tools to > avoid replaying event notifications that have already been received by > a user agent. This specification defines an extension to SIP events > that allows the subscriber to condition the subscription request to > whether the state has changed since the previous notification was > received. When such a condition is true, either the body of a > resulting event notification or the entire notification message is > suppressed. This "conditioning" of the subscription requests uses the > well-known concept of entity tags (eTags). > > Working Group Summary > > This document received extended working group review during a SIP WGLC > period that exceeded one year in duration. One critical clarification > came up in this review period: this specification does not provide > "versioning history" for events; rather it lets a subscriber know > whether the current event state is consistent with the event state as > currently known by that subscriber. The distinction is subtle. For > example, if the subscriber knows of event state "A", but the actual > state has changed to "B" and then back to "A" before a NOTIFY would > be sent (if the subscriber were offline for example), the subscriber > will not be informed about the B state through this specification. > > Following WGLC, the proto review process detected and corrected a > minor error in the ABNF, and further review by Adam Roach detected and > corrected problem related to suppressed NOTIFYs on initial dialogs. > > Document Quality > > The Open Mobile Alliance SIMPLE Presence specification references this > document, and has done so for several years. > > Personnel > > Dean Willis is this document's shepherd. > Robert Sparks is the responsible AD. From wwwrun@core3.amsl.com Wed Jan 27 11:43:58 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.6 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 42CB2E069F for ; Wed, 27 Jan 2010 11:43:58 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2slq5UUUSquL for ; Wed, 27 Jan 2010 11:43:58 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 28430E0697 for ; Wed, 27 Jan 2010 11:43:58 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 918013A698A; Wed, 27 Jan 2010 11:43:42 -0800 (PST) Subject: [rt.ietf.org #23356] Resolved: Re: Protocol Action: 'Extending ICMP for Interface and Next-hop Identification' to Proposed Standard From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23356 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 27 Jan 2010 11:43:42 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Wed Jan 27 11:44:46 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.6 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 8BBCBE069F for ; Wed, 27 Jan 2010 11:44:46 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWREuo5yuagC for ; Wed, 27 Jan 2010 11:44:46 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 75873E0697 for ; Wed, 27 Jan 2010 11:44:46 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id DC09B3A695E; Wed, 27 Jan 2010 11:44:30 -0800 (PST) Subject: [rt.ietf.org #23358] Resolved: Re: Protocol Action: 'An Extension to Session Initiation Protocol From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23358 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 27 Jan 2010 11:44:30 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Wed Jan 27 11:45:44 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.6 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 39BACE069F for ; Wed, 27 Jan 2010 11:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSdN80N4qdKC for ; Wed, 27 Jan 2010 11:45:44 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 2425DE0697 for ; Wed, 27 Jan 2010 11:45:44 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 840803A685F; Wed, 27 Jan 2010 11:45:28 -0800 (PST) Subject: [rt.ietf.org #23357] Resolved: Re: Protocol Action: 'Wrapped ESP for Traffic Visibility' to Proposed Standard From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23357 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 27 Jan 2010 11:45:28 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Thu Jan 28 12:46:14 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-202.5 required=5.0 tests=AWL,BAYES_00, SARE_SUB_OBFU_Q1,SUBJECT_IN_WHITELIST,USER_IN_WHITELIST autolearn=no version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id E14D8130003 for ; Thu, 28 Jan 2010 12:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SyrZJ-1mDEE for ; Thu, 28 Jan 2010 12:46:14 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id C30C9130001 for ; Thu, 28 Jan 2010 12:46:14 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 00E1C28C0FE; Thu, 28 Jan 2010 12:45:54 -0800 (PST) Subject: [rt.ietf.org #23401] AutoReply: Re: draft-ietf-roll-home-routing-reqs stuck? From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100128204551.GA395@rfc-editor.org> References: <6C66B845B4C040089C5198EA72E543AF@your029b8cecfe> <20100128204551.GA395@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23401 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 28 Jan 2010 12:45:54 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: draft-ietf-roll-home-routing-reqs stuck?", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #23401]. Please include the string: [rt.ietf.org #23401] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Hi Adrian, I'm not sure why the state hasn't change in the data-tracker, but the document is in the RFC Editor queue. 2010-01-21 draft-ietf-roll-home-routing-reqs-11.txt [C67] MISSREF REF draft-vasseur-roll-terminology NOT-RECEIVED A. Brandt, J. Buron, G. Porcu "Home Automation Routing Requirements in Low Power and Lossy Networks" Bytes: 40492 Working Group: Routing Over Low power and Lossy networks Please let us know if you have any questions. Thank you. RFC Editor On Thu, Jan 28, 2010 at 05:11:19PM +0000, Adrian Farrel wrote: > Hi, > > This I-D has been in "Approved-announcement sent" since 19 January. > > Has a wheel fallen off? > > A From wwwrun@core3.amsl.com Tue Feb 2 16:05:01 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.6 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id E0327130007 for ; Tue, 2 Feb 2010 16:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fq9gjqdwLpNO for ; Tue, 2 Feb 2010 16:05:01 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id B76CC130003 for ; Tue, 2 Feb 2010 16:05:01 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 50CFF3A69A7; Tue, 2 Feb 2010 16:04:21 -0800 (PST) Subject: [rt.ietf.org #23536] AutoReply: Re: Document Action: 'NSLP for Quality-of-Service Signaling' to Experimental RFC From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100203000459.GA30886@rfc-editor.org> References: <20100202150954.C59EB3A6B05@core3.amsl.com> <20100203000459.GA30886@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23536 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 02 Feb 2010 16:04:21 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'NSLP for Quality-of-Service Signaling' to Experimental RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #23536]. Please include the string: [rt.ietf.org #23536] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Tue, Feb 02, 2010 at 07:09:54AM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'NSLP for Quality-of-Service Signaling ' > as an Experimental RFC > > > This document is the product of the Next Steps in Signaling Working Group. > > The IESG contact persons are Magnus Westerlund and Lars Eggert. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-18.txt > > Technical Summary > > This draft proposes an NSIS Signaling Layer Protocol (NSLP) for signaling > QoS reservations in the Internet. The NSLP is the second layer in the > two-layer signaling model defined in RFC 4080. Together with GIST > (draft-ietf-nsis-ntlp), it provides functionality similar to RSVP and > extends it. The QoS NSLP is independent of the used QoS specification or > architecture and provides support for different reservation models. > > > Working Group Summary > > There have been several WGLC on the document, plus several pre-WGLCs > on the document. The editors have gotten extensive feedback from > implementors and have clarified text based upon the feedback. There > are 3 or more independent implementations of the QoS NSLP, and there > were multiple interop events in the past. > > Protocol Quality > > This document was reviewed by the working group chair as well as the > WG. We feel that this document is ready, and implementors feel that > the specification is implementable. > > Personal > > The document shepherd is Martin Stimerling and the responsible AD Magnus > Westerlund. From wwwrun@core3.amsl.com Tue Feb 2 16:05:15 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.6 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 75F8013000C for ; Tue, 2 Feb 2010 16:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y90tXGunQ+hr for ; Tue, 2 Feb 2010 16:05:15 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 55F42130003 for ; Tue, 2 Feb 2010 16:05:15 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id E49563A69D2; Tue, 2 Feb 2010 16:04:34 -0800 (PST) Subject: [rt.ietf.org #23537] AutoReply: Re: Protocol Action: 'Nameservers for IPv4 and IPv6 Reverse Zones' to BCP From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100203000513.GB30886@rfc-editor.org> References: <20100202213235.4472A3A6B72@core3.amsl.com> <20100203000513.GB30886@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23537 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 02 Feb 2010 16:04:34 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Nameservers for IPv4 and IPv6 Reverse Zones' to BCP", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #23537]. Please include the string: [rt.ietf.org #23537] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Tue, Feb 02, 2010 at 01:32:35PM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'Nameservers for IPv4 and IPv6 Reverse Zones ' > as a BCP > > This document has been reviewed in the IETF but is not the product of an > IETF Working Group. > > The IESG contact person is Ron Bonica. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-jabley-reverse-servers-01.txt > > Technical Summary > > This document specifies a stable naming scheme for the nameservers which > serve the zones IN-ADDR.ARPA and IP6.ARPA in the DNS. These zones contain > data which facilitate reverse mapping (address to name). > > Working Group Summary > > This is an individual submission. > > Document Quality > > The document has been reviewed by staff from ICANN/IANA, the RIPE NCC, > ARIN, LACNIC, APNIC and AfriNIC. It has been further reviewed by the IAB. > The document has been cited on the DNSOP mailing list, where one review > was published. No negative feedback has been received. The small number of > concerns raised by reviews by RIR staff, ICANN/IANA staff, the IAB and the > review sent to the DNSOP mailing list have been addressed. > > The document appears to represent consensus. > > Personnel > > Ron Bonica is document shepherd. From wwwrun@core3.amsl.com Tue Feb 2 17:07:48 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.6 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 12230130004 for ; Tue, 2 Feb 2010 17:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7T+uMjjtD-QD for ; Tue, 2 Feb 2010 17:07:47 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id E3CF5130003 for ; Tue, 2 Feb 2010 17:07:47 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 3EC4928C101; Tue, 2 Feb 2010 17:07:06 -0800 (PST) Subject: [rt.ietf.org #23536] Resolved: Re: Document Action: 'NSLP for Quality-of-Service Signaling' to Experimental RFC From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23536 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 02 Feb 2010 17:07:07 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Tue Feb 2 17:08:44 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.6 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 8D710130005 for ; Tue, 2 Feb 2010 17:08:44 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6FT1ElQL682 for ; Tue, 2 Feb 2010 17:08:44 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 77A38130004 for ; Tue, 2 Feb 2010 17:08:44 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id DCD7028C124; Tue, 2 Feb 2010 17:08:03 -0800 (PST) Subject: [rt.ietf.org #23537] Resolved: Re: Protocol Action: 'Nameservers for IPv4 and IPv6 Reverse Zones' to BCP From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23537 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 02 Feb 2010 17:08:03 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Thu Feb 4 16:23:57 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 4B6AD130006 for ; Thu, 4 Feb 2010 16:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QN9d8KC13LiH for ; Thu, 4 Feb 2010 16:23:57 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 24BDD130002 for ; Thu, 4 Feb 2010 16:23:57 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 9950D28C0F4; Thu, 4 Feb 2010 16:23:08 -0800 (PST) Subject: [rt.ietf.org #23604] AutoReply: Re: Document Action: 'Basic Socket Interface Extensions for Host Identity Protocol (HIP)' to Experimental RFC From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100205002354.GA25982@rfc-editor.org> References: <20100203160323.9952B3A6864@core3.amsl.com> <20100205002354.GA25982@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23604 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 04 Feb 2010 16:23:08 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'Basic Socket Interface Extensions for Host Identity Protocol (HIP)' to Experimental RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #23604]. Please include the string: [rt.ietf.org #23604] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Wed, Feb 03, 2010 at 08:03:23AM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'Basic Socket Interface Extensions for Host Identity Protocol (HIP) ' > as an Experimental RFC > > > This document is the product of the Host Identity Protocol Working Group. > > The IESG contact persons are Ralph Droms and Jari Arkko. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-12.txt > > Technical Summary > > This document defines extensions to the current sockets API for the > Host Identity Protocol (HIP). The extensions focus on the use of > public-key based identifiers discovered via DNS resolution, but > define also interfaces for manual bindings between HITs and > locators. With the extensions, the application can also support > more relaxed security models where the communication can be non-HIP > based, according to local policies. The extensions in this document > are experimental and provide basic tools for further > experimentation with policies. > > Working Group Summary > > Nothing in the WG process worth mentioning. > > Document Quality > > Currently, there are no implementations of this specification > but there are plans to implement it. > > Personnel > > Gonzalo Camarillo (Gonzalo.Camarillo@ericsson.com) is > the document shepherd. Ralph Droms (rdroms@cisco.com) is the > responsible AD. From wwwrun@core3.amsl.com Thu Feb 4 16:27:34 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id C287E130004 for ; Thu, 4 Feb 2010 16:27:34 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZWGbjn2scfx for ; Thu, 4 Feb 2010 16:27:34 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 99429130002 for ; Thu, 4 Feb 2010 16:27:34 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 12C843A67A4; Thu, 4 Feb 2010 16:26:45 -0800 (PST) Subject: [rt.ietf.org #23604] Resolved: Re: Document Action: 'Basic Socket Interface Extensions for Host Identity Protocol (HIP)' to Experimental RFC From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23604 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 04 Feb 2010 16:26:46 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From root@core3.amsl.com Fri Feb 5 13:30:56 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-202.2 required=5.0 tests=AWL,BAYES_00, J_CHICKENPOX_13,SUBJECT_IN_WHITELIST,USER_IN_WHITELIST autolearn=no version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 46C8D130003 for ; Fri, 5 Feb 2010 13:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWP6WgbnX+WN for ; Fri, 5 Feb 2010 13:30:56 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 252F0E06A6 for ; Fri, 5 Feb 2010 13:30:56 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 0) id 9890828C19C; Fri, 5 Feb 2010 13:30:02 -0800 (PST) From: IESG Secretary To: rfc-editor@rfc-editor.org Cc: iesg@ietf.org Subject: Removal of draft-ietf-l3vpn-ospfv3-pece from the RFC Editor Queue Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100205213003.9890828C19C@core3.amsl.com> Date: Fri, 5 Feb 2010 13:30:02 -0800 (PST) Dear RFC Editor, Due to comments received since the announcement of this document, the L3VPN working group, with the approval of the IESG, has decided to pull draft-ietf-l3vpn-ospfv3-pece from the RFC Editor Queue. Thank you, The IESG Secretary From wwwrun@core3.amsl.com Fri Feb 5 13:32:49 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-202.2 required=5.0 tests=AWL,BAYES_00, J_CHICKENPOX_13,SUBJECT_IN_WHITELIST,USER_IN_WHITELIST autolearn=no version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 13FDEE06A7 for ; Fri, 5 Feb 2010 13:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFbjtbR-YaK2 for ; Fri, 5 Feb 2010 13:32:48 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id E1F51E06A6 for ; Fri, 5 Feb 2010 13:32:48 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id D07E228C178; Fri, 5 Feb 2010 13:31:56 -0800 (PST) Subject: [rt.ietf.org #23645] AutoReply: Re: Removal of draft-ietf-l3vpn-ospfv3-pece from the RFC Editor Queue From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100205213246.GB28264@rfc-editor.org> References: <20100205213003.9890828C19C@core3.amsl.com> <20100205213246.GB28264@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23645 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 05 Feb 2010 13:31:56 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Removal of draft-ietf-l3vpn-ospfv3-pece from the RFC Editor Queue", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #23645]. Please include the string: [rt.ietf.org #23645] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- We have marked this document as withdraw, and removed it from our queue. Thank you. RFC Editor On Fri, Feb 05, 2010 at 01:30:02PM -0800, iesg-secretary wrote: > Dear RFC Editor, > > Due to comments received since the announcement of this document, the > L3VPN working group, with the approval of the IESG, has decided to pull > draft-ietf-l3vpn-ospfv3-pece from the RFC Editor Queue. > > Thank you, > > The IESG Secretary From wwwrun@core3.amsl.com Fri Feb 5 15:56:08 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-202.5 required=5.0 tests=AWL,BAYES_00, SUBJECT_IN_WHITELIST,USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id C5AB3130003 for ; Fri, 5 Feb 2010 15:56:08 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nw5aQ-eLo46i for ; Fri, 5 Feb 2010 15:56:08 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id A3617E05F9 for ; Fri, 5 Feb 2010 15:56:08 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 28AA63A6FA3; Fri, 5 Feb 2010 15:55:15 -0800 (PST) Subject: [rt.ietf.org #23645] Resolved: Re: Removal of draft-ietf-l3vpn-ospfv3-pece from the RFC Editor Queue From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23645 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 05 Feb 2010 15:55:16 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Thu Feb 11 14:12:55 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id B00C1E06D4 for ; Thu, 11 Feb 2010 14:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNKqensNFCrS for ; Thu, 11 Feb 2010 14:12:55 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 874E6E06D3 for ; Thu, 11 Feb 2010 14:12:55 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 51C4D28C237; Thu, 11 Feb 2010 14:11:37 -0800 (PST) Subject: [rt.ietf.org #23843] AutoReply: Re: Protocol Action: 'Right-to-left scripts for IDNA' to Proposed Standard From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100211221232.GA21730@rfc-editor.org> References: <20100210225616.685DA3A77C2@core3.amsl.com> <20100211221232.GA21730@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23843 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 11 Feb 2010 14:11:36 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Right-to-left scripts for IDNA' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #23843]. Please include the string: [rt.ietf.org #23843] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Wed, Feb 10, 2010 at 02:56:16PM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'Right-to-left scripts for IDNA ' > as a Proposed Standard > > > This document is the product of the Internationalized Domain Names in Applications, Revised Working Group. > > The IESG contact persons are Lisa Dusseault and Alexey Melnikov. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-idnabis-bidi-07.txt > > Technical Summary > > The Internationalized Domain Names for Applications (IDNA) revisions are > intended to reduce significantly IDNA dependency on specific versions of > the Unicode character coding system. The Working Group produced the > following documents representing a revision to the earlier “IDNA2003” > proposed standard [only RFC 3490 is specifically affected]: > > Definitions: draft-ietf-idnabis-defs-11.txt > Protocol: draft-ietf-idnabis-protocol-16.txt > Bi-Di: draft-ietf-idnabis-bidi-06a.txt > Tables: draft-ietf-idnabis-tables-07.txt > Rationale: draft-ietf-idnabis-rationale-13.txt > Mappings: draft-ietf-idnabis-mappings-04.txt > > Of these, Definitions, Protocol, Bi-Di and Tables are normative; > Rationale is informative and mappings is optional (Informational). > > > Working Group Summary > > The initial impetus for the revisiting of the IDNA2003 proposed standards > emerged in written form in RFC4690. An informal technical team worked to > develop a framework for consideration that was later discussed, edited, > and ratified to create the IDNABIS working group in 2008. Readers will > note that this is nearly 2010 but the new specifications bear the label > IDNA2008 because the work was started in that year. The documents > resulting from the IDNABIS Working Group effort have been extensively > discussed over a two year period by the WG and by interested parties > especially language experts in the Chinese, Japanese and Hangul spaces, > speakers of Hebrew, Indic languages as well as a working group of expert > Arabic speakers. The WG has had the participation of several Unicode > consortium representatives. There was controversy during the development > of these documents but a rough consensus has formed around the > recommendations. > > There was an impasse relating to mapping of Unicode characters into other > Unicode characters prior to the generation of a punycode equivalent string > to produce an A-label [please see the Definitions document]. This was > resolved by introducing the non-normative “mappings” document observing > ways in which this aspect of dealing with internationalized domain names > might be approached. The principal rationale for re-visiting the IDNA2003 > recommendations arose from field experience and a recommendation from the > IAB [RFC4690]. A major objective was to re-specify the standard in such a > way as to make it independent of changes to the Unicode code set > (something that evolves more or less continuously). The method for > achieving this is to use the Unicode properties feature (per > code-point/character) to determine whether the code point should be > allowed, disallowed or used only under certain conditions in domain name > labels. There remains the problem of deployment in a world of web servers, > browsers and other applications using domain names that may have already > implemented the IDNA2003 recommendations. > > Implementation tactics for dealing with the old and new specifications > may vary. Perfect backward compatibility with IDNA2003 was not possible > (without simply replicating it, negating the rationale for the > redefinition effort of IDNA2008). This is particularly true of the special > characters “esszet” or “sharp-S” used in German and the “final sigma” used > in Greek. These were mapped into other valid Unicode characters under > IDNA2003 but allowed in IDNA2008 because the Unicode code points for these > were introduced in the interim between IDNA2003 and IDNA2008 > standardization efforts. Registries have several implementation choices > including bundled registration of previously mapped and newly allowed > characters or rejection of conflicting new registrations. The treatment of > languages that are expressed in Right-to-Left form (see “Bi-Di” document) > has been revised relative to IDNA2003 and it is believed that the revision > is clearer and more precise in its form and limitations on the use of > numeric characters, for example. > > > Document Quality > > There are test implementations of the rules proposed by IDNA2008 but no > released operational software. Such implementations have awaited the > achievement of rough consensus on the controversial parts of the new > proposals. Inputs from special expert bodies such as a Korean expert > language group, an informal Arabic speakers group, and a number of > individual commentators from the Unicode community, among others, have > contributed to the documents as they now exist. Multiple implementations > of the Tables rules have confirmed the stability of the definitions under > distinct implementations. From wwwrun@core3.amsl.com Thu Feb 11 14:18:23 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 08256E06D7 for ; Thu, 11 Feb 2010 14:18:23 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTefmVtR7ZQA for ; Thu, 11 Feb 2010 14:18:22 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id DA649E06D3 for ; Thu, 11 Feb 2010 14:18:22 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 8952A3A75B3; Thu, 11 Feb 2010 14:17:06 -0800 (PST) Subject: [rt.ietf.org #23844] AutoReply: Re: Document Action: 'CAPWAP Protocol Base MIB' to Informational RFC From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100211221820.GB21730@rfc-editor.org> References: <20100211172820.9D78C28C21D@core3.amsl.com> <20100211221820.GB21730@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23844 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 11 Feb 2010 14:17:06 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'CAPWAP Protocol Base MIB' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #23844]. Please include the string: [rt.ietf.org #23844] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Thu, Feb 11, 2010 at 09:28:20AM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'CAPWAP Protocol Base MIB ' > as an Informational RFC > > > This document is the product of the Control And Provisioning of Wireless Access Points Working Group. > > The IESG contact persons are Dan Romascanu and Ron Bonica. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-capwap-base-mib-09.txt > > Technical Summary > > The CAPWAP Protocol defines a standard, interoperable > protocol, which enables an Access Controller (AC) to manage a > collection of Wireless Termination Points(WTPs). > > This document defines a MIB module that can be used to manage the > CAPWAP implementations. This MIB module covers both configuration > and WTP status-monitoring aspects of CAPWAP, and provides a way to > reuse MIB modules for any wireless technology. > > Working Group Summary > > The Working Group was initially chartered to issue Proposed Standard > but there was not enough working group involvement with this document > to warrant publication as a Proposed Standard. The document is > complete, went through full MIB Docotrs reviews, and there is no > disagreement about publishing it as Informational. > > Document Quality > > There is at least one implementation of this protocol underway. > At various phases of development the work was advised and reviewed by > David Harrington, Dan Romascanu, and Bert Wijnen for the MIB Doctors > team. > > Personnel > > Margaret Wassermann is the document shepherd. Dan Romascanu is > the responsible AD. Bert Wijnen is the MIB Doctor. From wwwrun@core3.amsl.com Thu Feb 11 14:30:14 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 24410E06D7 for ; Thu, 11 Feb 2010 14:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeEfHf8N4JnE for ; Thu, 11 Feb 2010 14:30:14 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 021E2E06D3 for ; Thu, 11 Feb 2010 14:30:14 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 9CF933A724C; Thu, 11 Feb 2010 14:28:57 -0800 (PST) Subject: [rt.ietf.org #23845] AutoReply: Re: Document Action: 'IPFIX Export per SCTP Stream' to Informational RFC From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100211223011.GC21730@rfc-editor.org> References: <20100211172702.2836628C117@core3.amsl.com> <20100211223011.GC21730@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23845 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 11 Feb 2010 14:28:57 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'IPFIX Export per SCTP Stream' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #23845]. Please include the string: [rt.ietf.org #23845] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Thu, Feb 11, 2010 at 09:27:02AM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'IPFIX Export per SCTP Stream ' > as an Informational RFC > > > This document is the product of the IP Flow Information Export Working Group. > > The IESG contact persons are Dan Romascanu and Ron Bonica. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-export-per-sctp-stream-06.txt > > Technical Summary > > This document specifies an improvement to the PR-SCTP > export specified in the IPFIX specifications in RFC5101. > This method offers several advantages such as the ability to > calculate Data Record losses for PR-SCTP, immediate export of > Template Withdrawal Messages, immediate reuse of Template IDs > within an SCTP stream, and reduced demands on the Collecting > Process. > > Working Group Summary > > This work was motivated by experiences made with early IPFIX > implementations. It was accepted with consensus as WG work item > and progressed within the WG. WG last call was conducted in August > 2008. Modifications based on received comments were applied until > November 2008. No more issues were brought up since then and > at the IETF meeting in March 2009 the WG confirmed at the session > that the document is ready for requesting publication. > > Document Quality > > IPFIX is implemented and deployed and this work is based on deployment > experience. The document underwent several reviews and a WG last call > in the IPFIX WG. This way, a high document quality has been achieved > already. > > Personnel > > Juergen Quittek is shepherding this document. Dan Romascanu is the > responsible Area Director. From wwwrun@core3.amsl.com Thu Feb 11 14:49:21 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 7EBBDE06D7 for ; Thu, 11 Feb 2010 14:49:21 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dB3C8Y8txk3v for ; Thu, 11 Feb 2010 14:49:21 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 5C36AE06D3 for ; Thu, 11 Feb 2010 14:49:21 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id D9EA128C236; Thu, 11 Feb 2010 14:48:04 -0800 (PST) Subject: [rt.ietf.org #23843] Resolved: Re: Protocol Action: 'Right-to-left scripts for IDNA' to Proposed Standard From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23843 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 11 Feb 2010 14:48:04 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Thu Feb 11 14:50:10 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 026AFE06D7 for ; Thu, 11 Feb 2010 14:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbM10msPKHAG for ; Thu, 11 Feb 2010 14:50:09 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id DBB4FE06D3 for ; Thu, 11 Feb 2010 14:50:09 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 378C728C250; Thu, 11 Feb 2010 14:48:52 -0800 (PST) Subject: [rt.ietf.org #23845] Resolved: Re: Document Action: 'IPFIX Export per SCTP Stream' to Informational RFC From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23845 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 11 Feb 2010 14:48:53 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Thu Feb 11 14:51:15 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 75AB2E06D7 for ; Thu, 11 Feb 2010 14:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zymFt2wevSBc for ; Thu, 11 Feb 2010 14:51:15 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 5C02BE06D3 for ; Thu, 11 Feb 2010 14:51:15 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id DF8C428C24A; Thu, 11 Feb 2010 14:49:58 -0800 (PST) Subject: [rt.ietf.org #23844] Resolved: Re: Document Action: 'CAPWAP Protocol Base MIB' to Informational RFC From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #23844 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 11 Feb 2010 14:49:58 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Wed Feb 17 11:51:26 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.4 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 0C96B130005 for ; Wed, 17 Feb 2010 11:51:26 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bx2NAQHlFvTa for ; Wed, 17 Feb 2010 11:51:25 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id DD1F1130002 for ; Wed, 17 Feb 2010 11:51:25 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id D74703A7F02; Wed, 17 Feb 2010 11:49:45 -0800 (PST) Subject: [rt.ietf.org #24020] AutoReply: Re: Document Action: 'Clearance Sponsor Attribute' to Informational RFC From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100217195123.GC19490@rfc-editor.org> References: <20100216204638.C810228C1AD@core3.amsl.com> <20100217195123.GC19490@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24020 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 17 Feb 2010 11:49:45 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'Clearance Sponsor Attribute' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #24020]. Please include the string: [rt.ietf.org #24020] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Tue, Feb 16, 2010 at 12:46:38PM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'Clearance Sponsor Attribute ' > as an Informational RFC > > This document has been reviewed in the IETF but is not the product of an > IETF Working Group. > > The IESG contact person is Tim Polk. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-turner-clearancesponsor-attribute-03.txt > > Technical Summary > > This document defines the clearance sponsor attribute. This attribute > may be carried in a public key certificate in the Subject Directory > Attributes extension, in an attribute certificate in the attribute > field, in a directory as an attribute, or in protocols that support > attributes. > > Discussion Summary > > The -00 version was reviewed by Kurt Zeilenga. He suggested instead of > using UTF8String that the attribute be a DirectoryString and use the > caseIgnoreMatch matching rule. These changes were adopted, as they were > more than reasonable. > > Document Quality > > This document is a short document that defines an attribute and uses an > already defined matching rule. > > Personnel > > Tim Polk is the responsible AD and the document Shepherd. From wwwrun@core3.amsl.com Wed Feb 17 11:51:36 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.4 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id A64D0130007 for ; Wed, 17 Feb 2010 11:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+3FM7CbIWUp for ; Wed, 17 Feb 2010 11:51:36 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 8AA57130005 for ; Wed, 17 Feb 2010 11:51:36 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 858103A7F02; Wed, 17 Feb 2010 11:49:56 -0800 (PST) Subject: [rt.ietf.org #24021] AutoReply: Re: Document Action: 'Elliptic Curve Private Key Structure' to Informational RFC From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100217195134.GD19490@rfc-editor.org> References: <20100216204925.A0A013A709E@core3.amsl.com> <20100217195134.GD19490@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24021 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 17 Feb 2010 11:49:56 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'Elliptic Curve Private Key Structure' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #24021]. Please include the string: [rt.ietf.org #24021] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Tue, Feb 16, 2010 at 12:49:25PM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'Elliptic Curve Private Key Structure ' > as an Informational RFC > > This document has been reviewed in the IETF but is not the product of an > IETF Working Group. > > The IESG contact person is Tim Polk. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-turner-ecprivatekey-04.txt > > Technical Summary > > This document specifies the syntax and semantics for Elliptic Curve (EC) > private key information. This syntax and semantics defined therein are > based on a similar syntax and semantics defined in Standards for > Efficient Cryptography Group (SECG). It is profiled for the IETF as the > ECPublicKey structure from SECG is profiled for the IETF in RFC 5480. > > Working Group Summary > > The publication announcement for this I-D was forwarded to the PKIX WG > for comment. Reviews resulted in 3 versions. The 1st revision replaced > the conversion routine with an existing routine from RFC 3447 (reuse is > better than reinventing), added an acknowledgments section, and updated > a reference for Base64 encodings. The 2nd revision added an other > considerations section to discuss transfer and local storage encoding > and required the presence of parameters. > > Document Quality > > This text is short (4 pages) and so is the ASN.1 (5 lines). It is based > on the SECG document whose text and ASN.1 has been stable for many > years. OpenSSL supports the structure as defined in this document. > > Personnel > > Carl Wallace is the document Shepherd. Tim Polk is the responsible AD. From wwwrun@core3.amsl.com Wed Feb 17 11:51:48 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.4 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id B76A0130009 for ; Wed, 17 Feb 2010 11:51:48 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvdQORPrl6X7 for ; Wed, 17 Feb 2010 11:51:48 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 9A320130008 for ; Wed, 17 Feb 2010 11:51:48 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 963753A7F06; Wed, 17 Feb 2010 11:50:08 -0800 (PST) Subject: [rt.ietf.org #24022] AutoReply: Re: Document Action: 'Device Owner Attribute' to Informational RFC From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100217195146.GE19490@rfc-editor.org> References: <20100216210325.CEF1228C1C8@core3.amsl.com> <20100217195146.GE19490@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24022 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 17 Feb 2010 11:50:08 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'Device Owner Attribute' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #24022]. Please include the string: [rt.ietf.org #24022] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Tue, Feb 16, 2010 at 01:03:25PM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'Device Owner Attribute ' > as an Informational RFC > > This document has been reviewed in the IETF but is not the product of an > IETF Working Group. > > The IESG contact person is Tim Polk. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-turner-deviceowner-attribute-03.txt > > Technical Summary > > This document defines the deviceOwner attribute. This attribute may be > carried in a public key certificate in the Subject Directory Attributes > extension, in an attribute certificate in the attribute field, in a > directory as an attribute, or in protocols that support attributes. > > Discussion Summary > > The -00 version was reviewed by Kurt Zeilenga. A match rule was added > to the definition to ensure a proper match can be performed between a > presented attribute and a stored attribute. > > Document Quality > > This document is a short document that defines an attribute a matching > rule. > > Personnel > > Tim Polk is the responsible AD and is acting as document Shepherd. From wwwrun@core3.amsl.com Wed Feb 17 11:51:59 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 88A0013000A for ; Wed, 17 Feb 2010 11:51:59 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1r6XA3-DL3r for ; Wed, 17 Feb 2010 11:51:59 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 6EAF5130008 for ; Wed, 17 Feb 2010 11:51:59 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 6B72D3A7F06; Wed, 17 Feb 2010 11:50:19 -0800 (PST) Subject: [rt.ietf.org #24023] AutoReply: Re: Protocol Action: 'Support of address families in OSPFv3' to Proposed Standard From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100217195157.GF19490@rfc-editor.org> References: <20100217145516.65F993A7ECB@core3.amsl.com> <20100217195157.GF19490@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24023 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 17 Feb 2010 11:50:19 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Support of address families in OSPFv3' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #24023]. Please include the string: [rt.ietf.org #24023] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Wed, Feb 17, 2010 at 06:55:16AM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'Support of address families in OSPFv3 ' > as a Proposed Standard > > > This document is the product of the Open Shortest Path First IGP Working Group. > > The IESG contact persons are Ross Callon and Adrian Farrel. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ospf-af-alt-10.txt > > Technical Summary > > This document describes a mechanism for supporting multiple address > families in OSPFv3 using multiple instances. It maps an address > family (AF) to an OSPFv3 instance using the Instance ID field in the > OSPFv3 packet header. For example, this supports a requirement to > advertise other AFs in OSPFv3 including multicast IPv6, unicast IPv4, > and multicast IPv4. This approach is fairly simple and minimizes > extensions to OSPFv3 for supporting multiple AFs. > > Working Group Summary > > No controversy reported (see PROTO writeup by Acee Lindem in the > ID tracker). > > Document Quality > > The document has been well reviewed. Dave Ward, in his capacity > as Routing AD, reviewed it several times. There are several > implementations, at least one of which is commercially > available. > > Personnel > > Acee Lindem is the Document Shepherd for this document. Ross Callon > is the Responsible Area Director. From wwwrun@core3.amsl.com Wed Feb 17 11:52:08 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-104.1 required=5.0 tests=AWL,BAYES_00, HELO_MISMATCH_ORG,HOST_MISMATCH_COM,RCVD_IN_DNSWL_MED,USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 7834E13000C for ; Wed, 17 Feb 2010 11:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyXlbQzFGoNk for ; Wed, 17 Feb 2010 11:52:08 -0800 (PST) Received: from mail.ietf.org (core3.amsl.com [64.170.98.32]) by rfc-editor.org (Postfix) with ESMTP id 5268813000A for ; Wed, 17 Feb 2010 11:52:08 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 478C428C0EF; Wed, 17 Feb 2010 11:50:28 -0800 (PST) Subject: [rt.ietf.org #24024] AutoReply: Re: Document Action: 'Integration of Robust Header Compression over IPsec Security Associations' to Informational RFC From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100217195206.GG19490@rfc-editor.org> References: <20100217145653.ED3723A7ED3@core3.amsl.com> <20100217195206.GG19490@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24024 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 17 Feb 2010 11:50:28 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'Integration of Robust Header Compression over IPsec Security Associations' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #24024]. Please include the string: [rt.ietf.org #24024] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Wed, Feb 17, 2010 at 06:56:53AM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'Integration of Robust Header Compression over IPsec Security > Associations ' > as an Informational RFC > > > This document is the product of the Robust Header Compression Working Group. > > The IESG contact persons are Magnus Westerlund and Lars Eggert. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-rohc-hcoipsec-13.txt > > Technical Summary > > IP Security (IPsec) provides various security services for > IP traffic. However, the benefits of IPsec come at the cost > of increased overhead. This document outlines a framework > for integrating Robust Header Compression (ROHC) over IPsec > (ROHCoIPsec). By compressing the inner headers of IP > packets, ROHCoIPsec proposes to reduce the amount of > overhead associated with the transmission of traffic over > IPsec Security Associations (SAs). > > > Working Group Summary > > The document represents rough consensus of the working group. > > Document Quality > > The document have been reviewed extensively by both members > from the ipsecme and the rohc working groups. During the WG > Last-Call the document was reviewed by the committed WG > reviewers Robert A. Stangarone Jr. and Yoav Nir. > > Personnel > > Carl Knutsson is document shepherd and Magnus Westerlund > responsible AD. From wwwrun@core3.amsl.com Wed Feb 17 11:52:19 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-104.2 required=5.0 tests=AWL,BAYES_00, HELO_MISMATCH_ORG,HOST_MISMATCH_COM,RCVD_IN_DNSWL_MED,USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 69B5613000A for ; Wed, 17 Feb 2010 11:52:19 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id anh50dP-4H0M for ; Wed, 17 Feb 2010 11:52:19 -0800 (PST) Received: from mail.ietf.org (core3.amsl.com [64.170.98.32]) by rfc-editor.org (Postfix) with ESMTP id 4D549130009 for ; Wed, 17 Feb 2010 11:52:19 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 48A833A7F05; Wed, 17 Feb 2010 11:50:39 -0800 (PST) Subject: [rt.ietf.org #24025] AutoReply: Re: Protocol Action: 'IKEv2 Extensions to Support Robust Header Compression over IPsec' to Proposed Standard From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100217195217.GH19490@rfc-editor.org> References: <20100217145818.56FEC3A7ED6@core3.amsl.com> <20100217195217.GH19490@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24025 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 17 Feb 2010 11:50:39 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'IKEv2 Extensions to Support Robust Header Compression over IPsec' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #24025]. Please include the string: [rt.ietf.org #24025] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Wed, Feb 17, 2010 at 06:58:18AM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'IKEv2 Extensions to Support Robust Header Compression over IPsec ' > as a Proposed Standard > > > This document is the product of the Robust Header Compression Working Group. > > The IESG contact persons are Magnus Westerlund and Lars Eggert. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-rohc-ikev2-extensions-hcoipsec-12.txt > > Technical Summary > > As part of the ROHCoIPsec framework, this document defines > extensions to Internet Key Exchange version 2 (IKEv2) to > signal ROHC parameters between IPsec peers. > > > Working Group Summary > > The document represents rough consensus of the working group. > > Document Quality > > The document have been reviewed extensively by both members > from the ipsecme and the rohc working groups. During the WG > Last-Call the document was reviewed by the committed WG > reviewers Robert A. Stangarone Jr. and Yoav Nir. > > Personnel > > Carl Knutsson is document shepherd and Magnus Westerlund is Responsible > AD. From wwwrun@core3.amsl.com Wed Feb 17 11:52:27 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 2265C13000C for ; Wed, 17 Feb 2010 11:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKJBPkzb5nO8 for ; Wed, 17 Feb 2010 11:52:27 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 06F61130008 for ; Wed, 17 Feb 2010 11:52:27 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 028133A7F08; Wed, 17 Feb 2010 11:50:46 -0800 (PST) Subject: [rt.ietf.org #24026] AutoReply: Re: Protocol Action: 'IPsec Extensions to Support Robust Header Compression over IPsec' to Proposed Standard From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100217195225.GI19490@rfc-editor.org> References: <20100217145937.587613A7ED1@core3.amsl.com> <20100217195225.GI19490@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24026 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 17 Feb 2010 11:50:46 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'IPsec Extensions to Support Robust Header Compression over IPsec' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #24026]. Please include the string: [rt.ietf.org #24026] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue.html Please let us know if you have any questions. Thank you. RFC Editor On Wed, Feb 17, 2010 at 06:59:37AM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'IPsec Extensions to Support Robust Header Compression over IPsec ' > as a Proposed Standard > > > This document is the product of the Robust Header Compression Working Group. > > The IESG contact persons are Magnus Westerlund and Lars Eggert. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-rohc-ipsec-extensions-hcoipsec-08.txt > > Technical Summary > > Integrating ROHC with IPsec (ROHCoIPsec) offers the combined > benefits of IP security services and efficient bandwidth > utilization. This document describes the IPsec extensions to > the Security Policy Database (SPD) and the Security > Association Database (SAD) required to support ROHCoIPsec. > > Working Group Summary > > The document represents rough consensus of the working group. > > Document Quality > > The document have been reviewed extensively by both members > from the ipsecme and the rohc working groups. During the WG > Last-Call the document was reviewed by the committed WG > reviewers Robert A. Stangarone Jr. and Yoav Nir. > > > Personnel > > Carl Knutsson is document shepherd and Magnus Westerlund > responsible AD. From wwwrun@core3.amsl.com Wed Feb 17 12:08:38 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id D4956130005 for ; Wed, 17 Feb 2010 12:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KsHan+Ii2W2z for ; Wed, 17 Feb 2010 12:08:38 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id AEC85130002 for ; Wed, 17 Feb 2010 12:08:38 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 960713A7F03; Wed, 17 Feb 2010 12:06:58 -0800 (PST) Subject: [rt.ietf.org #24026] Resolved: Re: Protocol Action: 'IPsec Extensions to Support Robust Header Compression over IPsec' to Proposed Standard From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24026 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 17 Feb 2010 12:06:58 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Wed Feb 17 12:09:30 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 48F65130005 for ; Wed, 17 Feb 2010 12:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpQrzAEhO75L for ; Wed, 17 Feb 2010 12:09:30 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 2F806130002 for ; Wed, 17 Feb 2010 12:09:30 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 18CD628C0EF; Wed, 17 Feb 2010 12:07:49 -0800 (PST) Subject: [rt.ietf.org #24022] Resolved: Re: Document Action: 'Device Owner Attribute' to Informational RFC From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24022 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 17 Feb 2010 12:07:50 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Wed Feb 17 12:10:16 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 06E58130005 for ; Wed, 17 Feb 2010 12:10:16 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nHX88vWe71X for ; Wed, 17 Feb 2010 12:10:15 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id E657C130002 for ; Wed, 17 Feb 2010 12:10:15 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id D02A728C1C9; Wed, 17 Feb 2010 12:08:35 -0800 (PST) Subject: [rt.ietf.org #24021] Resolved: Re: Document Action: 'Elliptic Curve Private Key Structure' to Informational RFC From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24021 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 17 Feb 2010 12:08:35 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Wed Feb 17 12:12:20 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 074E9130005 for ; Wed, 17 Feb 2010 12:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lD3koq5cdjBm for ; Wed, 17 Feb 2010 12:12:19 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id DBBFC130002 for ; Wed, 17 Feb 2010 12:12:19 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id BB95028C0E7; Wed, 17 Feb 2010 12:10:39 -0800 (PST) Subject: [rt.ietf.org #24024] Resolved: Re: Document Action: 'Integration of Robust Header Compression over IPsec Security Associations' to Informational RFC From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24024 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 17 Feb 2010 12:10:39 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Wed Feb 17 12:13:49 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 0BA11130005 for ; Wed, 17 Feb 2010 12:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzR4YrwIt9f8 for ; Wed, 17 Feb 2010 12:13:48 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id E3EC1130002 for ; Wed, 17 Feb 2010 12:13:48 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id B39A428C0E7; Wed, 17 Feb 2010 12:12:08 -0800 (PST) Subject: [rt.ietf.org #24025] Resolved: Re: Protocol Action: 'IKEv2 Extensions to Support Robust Header Compression over IPsec' to Proposed Standard From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24025 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 17 Feb 2010 12:12:08 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Wed Feb 17 12:40:03 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id CAED9130003 for ; Wed, 17 Feb 2010 12:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOxdo9bnoP5E for ; Wed, 17 Feb 2010 12:40:03 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 9C273130002 for ; Wed, 17 Feb 2010 12:40:03 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 705D43A7F18; Wed, 17 Feb 2010 12:38:23 -0800 (PST) Subject: [rt.ietf.org #24020] Resolved: Re: Document Action: 'Clearance Sponsor Attribute' to Informational RFC From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24020 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 17 Feb 2010 12:38:23 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Wed Feb 17 12:41:10 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 75070130003 for ; Wed, 17 Feb 2010 12:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkDolTEoQf5a for ; Wed, 17 Feb 2010 12:41:10 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 5E8D0130002 for ; Wed, 17 Feb 2010 12:41:10 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 976D328C100; Wed, 17 Feb 2010 12:39:29 -0800 (PST) Subject: [rt.ietf.org #24023] Resolved: Re: Protocol Action: 'Support of address families in OSPFv3' to Proposed Standard From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24023 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 17 Feb 2010 12:39:29 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Wed Feb 17 15:11:24 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id C713F130008 for ; Wed, 17 Feb 2010 15:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1WQnglggH8p for ; Wed, 17 Feb 2010 15:11:24 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id A579D130007 for ; Wed, 17 Feb 2010 15:11:24 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 186D03A7DD1; Wed, 17 Feb 2010 15:09:43 -0800 (PST) Subject: [rt.ietf.org #24030] AutoReply: Re: Document Action: 'The OAuth 1.0 Protocol' to Informational RFC From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100217231122.GA17396@rfc-editor.org> References: <20100217230136.8498E28C287@core3.amsl.com> <20100217231122.GA17396@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24030 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 17 Feb 2010 15:09:44 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'The OAuth 1.0 Protocol' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #24030]. Please include the string: [rt.ietf.org #24030] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue2.html Please let us know if you have any questions. Thank you. RFC Editor On Wed, Feb 17, 2010 at 03:01:36PM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'The OAuth 1.0 Protocol ' > as an Informational RFC > > This document has been reviewed in the IETF but is not the product of an > IETF Working Group. > > The IESG contact person is Lisa Dusseault. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-hammer-oauth-10.txt > > Technical Summary > > OAuth provides a method for Web clients to access Web server resources > > on behalf of a resource owner (such as a different client or an end- > user). It also provides a process for end-users to authorize third > party access to their server resources without sharing their > credentials (typically, a username and password pair), using user- > agent redirections. > > > Working Group Summary > > This is not a WG product. However, it was reviewed by the OAUTH > WG. The OAUTH WG is working on a standards track revision of OAUTH, > but in the meantime, this is a useful work product because it fixes > several errata in the pre-IETF version of the protocol and establishes > an IETF-reviewed specification for the community-implemented protocol. > > Document Quality > > There are many existing implementations of this specification, > because it was the subject of an ad-hoc "standardization" effort > involving quite a few individuals and implementors. > > Personnel > > Lisa Dusseault is the sponsor of the document. > > Note to RFC Editor > > Please make the following changes in the published RFC > > OLD: > The OAuth protocol was originally created by a small community of web > developers from a variety of websites and other Internet services, > who wanted to solve the common problem of enabling delegated access > to protected resources. The resulting OAuth protocol was stabilized > at version 1.0 in October 2007 and published at the oauth.net > website [1]. > > This specification provides an informational documentation of OAuth > Core 1.0 Revision A as finalized in June 2009, addressing several > errata reported since that time, as well as numerous editorial > clarifications. It is not an item of the IETF's OAuth Working Group, > which at the time of writing is working on an OAuth version that can > be appropriate for publication on the standards track. > > NEW: > The OAuth protocol was originally created by a small community of web > developers from a variety of websites and other Internet services, > who wanted to solve the common problem of enabling delegated access > to protected resources. The resulting OAuth protocol was stabilized > at version 1.0 in October 2007, and revised in June 2009 (revision A) as > > published at . > > This specification provides an informational documentation of OAuth > Core 1.0 Revision A, addressing several errata reported since that time, > > as well as numerous editorial clarifications. While this specification > is not > an item of the IETF's OAuth Working Group, which at the time of writing > is > working on an OAuth version that can be appropriate for publication on > the > standards track, it has been transferred to the IETF for change control > by > authors of the original work. From wwwrun@core3.amsl.com Wed Feb 17 15:16:33 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 5A3D2130005 for ; Wed, 17 Feb 2010 15:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qUnqT9AWK-p for ; Wed, 17 Feb 2010 15:16:33 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 3CFB9130002 for ; Wed, 17 Feb 2010 15:16:33 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 99D8A3A78F4; Wed, 17 Feb 2010 15:14:52 -0800 (PST) Subject: [rt.ietf.org #24030] Resolved: Re: Document Action: 'The OAuth 1.0 Protocol' to Informational RFC From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24030 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 17 Feb 2010 15:14:52 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Fri Feb 19 11:24:33 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 54893E06E5 for ; Fri, 19 Feb 2010 11:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ybw7NS0OhJvq for ; Fri, 19 Feb 2010 11:24:33 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 3315CE06E4 for ; Fri, 19 Feb 2010 11:24:33 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 109B228C12F; Fri, 19 Feb 2010 11:22:44 -0800 (PST) Subject: [rt.ietf.org #24094] AutoReply: Re: Protocol Action: 'RSVP-TE Signaling Extension For Management Plane To Control Plane LSP Handover In A GMPLS Enabled Transport Network.' to Proposed Standard From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100219192429.GA14524@rfc-editor.org> References: <20100219152749.8F4153A7EB6@core3.amsl.com> <20100219192429.GA14524@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24094 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 19 Feb 2010 11:22:45 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'RSVP-TE Signaling Extension For Management Plane To Control Plane LSP Handover In A GMPLS Enabled Transport Network.' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #24094]. Please include the string: [rt.ietf.org #24094] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue2.html Please let us know if you have any questions. Thank you. RFC Editor On Fri, Feb 19, 2010 at 07:27:49AM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'RSVP-TE Signaling Extension For Management Plane To Control Plane LSP > Handover In A GMPLS Enabled Transport Network. ' > as a Proposed Standard > > > This document is the product of the Common Control and Measurement Plane Working Group. > > The IESG contact persons are Adrian Farrel and Ross Callon. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-spc-rsvpte-ext-07.txt > > Technical Summary > > This memo describes an extension to Generalized Multi-Protocol > Label Switching signaling that enables the transfer of connection > ownership between the Management and the Control Planes. Such a > transfer is referred to as a Handover. This document defines all > Handover related procedures. This includes the handling of failure > conditions and subsequent rversion to original state. A basic > premise of the extension is that the handover procedures must never > impact an already established data plane. > > Working Group Summary > > This document received adequate attention and discussion in its early > revisions. The document has been laregly stable for quite some time, > mainly needing revisions as part of the publication process. > > Document Quality > > There have been no public statements related to intent to implement, > but it is expected that some/all of the primary Authors plan to > implement. > > Personnel > > Lou Berger is the Document Shepherd for this document. > Adrian Farrel is the Responsible Area Director. From wwwrun@core3.amsl.com Fri Feb 19 11:24:44 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 220BFE06E5 for ; Fri, 19 Feb 2010 11:24:44 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMYnviHXAWFE for ; Fri, 19 Feb 2010 11:24:44 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 07865E06E4 for ; Fri, 19 Feb 2010 11:24:44 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 053203A7D83; Fri, 19 Feb 2010 11:22:55 -0800 (PST) Subject: [rt.ietf.org #24095] AutoReply: Re: Protocol Action: 'Clearance Attribute and Authority Clearance Constraints From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100219192442.GB14524@rfc-editor.org> References: <20100219153000.3B5CE3A7F80@core3.amsl.com> <20100219192442.GB14524@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24095 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 19 Feb 2010 11:22:56 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Clearance Attribute and Authority Clearance Constraints", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #24095]. Please include the string: [rt.ietf.org #24095] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue2.html Please let us know if you have any questions. Thank you. RFC Editor On Fri, Feb 19, 2010 at 07:30:00AM -0800, iesg-secretary wrote: > Certificate Extension' to Proposed Standard > > The IESG has approved the following document: > > - 'Clearance Attribute and Authority Clearance Constraints Certificate > Extension ' > as a Proposed Standard > > > This document is the product of the Public-Key Infrastructure (X.509) Working Group. > > The IESG contact persons are Tim Polk and Pasi Eronen. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pkix-authorityclearanceconstraints-03.txt > > Technical Summary > > This document defines the syntax and semantics for the Clearance > attribute and the Authority Clearance Constraints extension in X.509 > certificates. The Clearance attribute is used to indicate the > clearance held by the subject. The Clearance attribute may appear in > the subject directory attributes extension of a public key > certificate or in the attributes field of an attribute certificate. > The Authority Clearance Constraints certificate extension values in a > Trust Anchor (TA), CA public key certificates, and an Attribute > Authority (AA) public key certificate in a public key certification > path constrain the effective Clearance of the subject. > > Working Group Summary > > This ID was discussed on the mailing list and at multiple meetings. > There was initially some controversy about whether or not these > extensions were reasonable. Eventually, the working group agreed > that they were applicable and important to a set of internet users. > All PKIX WG Last Call issues have been resolved. Discussion during > PKIX WG Last Call demonstrated working group consensus. This > document has strong PKIX WG support. > > Document Quality > > There are no known implementations, but some WG members > have expressed interest in implementing this ID. Russ Housley > also reviewed this document. > > Personnel > > Steve Kent is the document Shepherd. Tim Polk is the responsible > Security Area AD. > > RFC Editor Note > > Please make the following subsitutions: > > In Section 1: > > OLD > > Since [RFC3281bis] does not permit chain of ACs > > NEW > > Since [RFC3281bis] does not permit chains of ACs > > In Section 1.2 > > OLD > > All X.509 PKC [RFC5280] extensions are defined using ASN.1 [X.680]. > All X.509 AC [RFC3281bis] extensions are defined using ASN.1 [X.680]. > > NEW > > All X.509 PKC [RFC5280] extensions are defined using ASN.1 [X.680]. > All X.509 AC [RFC3281bis] extensions are defined using ASN.1 [X.680]. > Note that [X.680] is the 2002 version of ASN.1, which is the most > recent version with freeware compiler support. > > In Section 2: > > OLD > > The ASN.1 syntax for the Clearance attribute is as follows [PKI-ASN]: > > > > > > NEW > > The ASN.1 syntax for the Clearance attribute is defined in [PKI-ASN] > and > that RFC provides the normative definition. The ASN.1 syntax for > Clearance attribute is as follows: > > In Section 5.1: > > OLD > > Authority Clearance Constraints are collected from the user input, > the trust anchor and all the PKCs in a PKC certification path. > > NEW > > Authority Clearance Constraints are collected from the user input, > the trust anchor and all the PKCs in the AA PKC certification path. > > In Section 7: > > OLD > The algorithm described in here has the idempotency, associative, and > commutative properties, like the rest of the processing rules in this > document. > > NEW > > The algorithm described in here has the idempotency, associative, and > commutative properties > > In Section 9: > > OLD > > Certificate issuers must recognize that absence of the > AuthorityClearanceConstraints in a CA or AA certificate means that in > terms of the clearance, the subject Authority is not constrained. > > NEW > > Certificate issuers must recognize that absence of the > AuthorityClearanceConstraints in a TA, in a CA certificate, or in an > AA certificate means that in terms of the clearance, the subject > Authority is not constrained. > > in Appendix A: > > OLD > > -- The following is a '02 version for clearance. > > NEW > > -- The following is an '02 ASN.1 version for clearance. From wwwrun@core3.amsl.com Fri Feb 19 11:24:52 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id B766F130005 for ; Fri, 19 Feb 2010 11:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqw0ih6P8Jo7 for ; Fri, 19 Feb 2010 11:24:52 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 9B518130002 for ; Fri, 19 Feb 2010 11:24:52 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 96B5628C170; Fri, 19 Feb 2010 11:23:04 -0800 (PST) Subject: [rt.ietf.org #24096] AutoReply: Re: Protocol Action: 'Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions' to Proposed Standard From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100219192450.GC14524@rfc-editor.org> References: <20100219153213.50F163A7CBC@core3.amsl.com> <20100219192450.GC14524@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24096 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 19 Feb 2010 11:23:04 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #24096]. Please include the string: [rt.ietf.org #24096] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue2.html Please let us know if you have any questions. Thank you. RFC Editor On Fri, Feb 19, 2010 at 07:32:13AM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and > Channel Set Label Extensions ' > as a Proposed Standard > > > This document is the product of the Common Control and Measurement Plane Working Group. > > The IESG contact persons are Adrian Farrel and Ross Callon. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-dcsc-channel-ext-04.txt > > Technical Summary > > This document describes two technology-independent extensions to > Generalized Multi-Protocol Label Switching. The first extension > defines the new switching type Data Channel Switching Capable. Data > Channel Switching Capable interfaces are able to support switching of > the whole digital channel presented on single channel interfaces. > The second extension defines a new type of generalized label and > updates related objects. The new label is called the Generalized > Channel_Set Label and allows more than one data plane label to be > controlled as part of an LSP. > > Working Group Summary > > Nothing to report. > > Document Quality > > There are no known implementations, but it is expected that several > vendors plan to implement. > > Personnel > > Deborah Brungard (db3546@att.com) is the Document Shepherd. > Adrian Farrel (adrian.farrel@huawei.com) is the Responsible AD > > RFC Editor Note > > RFC Editor - we suggest that you treat this I-D as part of a cluster > including the following five documents. > > draft-ietf-ccamp-ethernet-traffic-parameters > draft-ietf-ccamp-gmpls-dcsc-channel-ext > draft-ietf-ccamp-gmpls-ether-svcs > draft-ietf-ccamp-gmpls-mef-uni > draft-ietf-ccamp-gmpls-mln-extensions > > IANA Note > > IANA please note the requested update to IANAGmplsSwitchingTypeTC at > http://www.iana.org/assignments/ianagmplstc-mib From wwwrun@core3.amsl.com Fri Feb 19 11:25:02 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.4 required=5.0 tests=AWL,BAYES_00, SARE_SUB_OBFU_Q1,USER_IN_WHITELIST autolearn=no version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id B453B130006 for ; Fri, 19 Feb 2010 11:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pMTVbS7EoL6 for ; Fri, 19 Feb 2010 11:25:02 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 5DA94130002 for ; Fri, 19 Feb 2010 11:25:02 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 5F9403A7D7E; Fri, 19 Feb 2010 11:23:13 -0800 (PST) Subject: [rt.ietf.org #24097] AutoReply: Re: Document Action: 'QoS NSLP QSPEC Template' to Experimental RFC From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100219192500.GD14524@rfc-editor.org> References: <20100219153403.8372828C2CC@core3.amsl.com> <20100219192500.GD14524@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24097 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 19 Feb 2010 11:23:14 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'QoS NSLP QSPEC Template' to Experimental RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #24097]. Please include the string: [rt.ietf.org #24097] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue2.html Please let us know if you have any questions. Thank you. RFC Editor On Fri, Feb 19, 2010 at 07:34:03AM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'QoS NSLP QSPEC Template ' > as an Experimental RFC > > > This document is the product of the Next Steps in Signaling Working Group. > > The IESG contact persons are Magnus Westerlund and Lars Eggert. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-24.txt > > Technical Summary > > The QoS NSLP protocol is used to signal QoS reservations and is > independent of a specific QoS model (QOSM) such as IntServ or > DiffServ. Rather, all information specific to a QOSM is encapsulated > in a separate object, the QSPEC. This document defines a template > for the QSPEC including a number of QSPEC parameters. The QSPEC > parameters provide a common language to be re-used in several QOSMs > and thereby aim to ensure the extensibility and interoperability of > QoS NSLP. The node initiating the NSIS signaling adds an initiator > QSPEC, which indicates the QSPEC parameters that must be interpreted > by the downstream nodes less the reservation fails, thereby ensuring > the intention of the NSIS initiator is preserved along the signaling > path. > > > Working Group Summary > There have been several WGLC on the document, plus several pre-WGLCs > on the document. The editors have gotten extensive feedback from the WG > and outside of the WG. > > Document Quality > This document was reviewed by the working group chair as well as the > WG. We feel that this document is ready. > > Personal > The document shepherd is Martin Stimerling and the responsible AD Magnus > Westerlund. From wwwrun@core3.amsl.com Fri Feb 19 11:25:11 2010 Return-Path: X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id F1400130005 for ; Fri, 19 Feb 2010 11:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeHa97BOdTGP for ; Fri, 19 Feb 2010 11:25:10 -0800 (PST) Received: from mail.ietf.org (core3.amsl.com [64.170.98.32]) by rfc-editor.org (Postfix) with ESMTP id D5E5B130001 for ; Fri, 19 Feb 2010 11:25:10 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id D93493A7D83; Fri, 19 Feb 2010 11:23:22 -0800 (PST) Subject: [rt.ietf.org #24098] AutoReply: Re: Document Action: 'Y.1541-QOSM -- Model for Networks Using Y.1541 QoS Classes' to Experimental RFC From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100219192509.GE14524@rfc-editor.org> References: <20100219153524.1BA9628C0E8@core3.amsl.com> <20100219192509.GE14524@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24098 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 19 Feb 2010 11:23:22 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'Y.1541-QOSM -- Model for Networks Using Y.1541 QoS Classes' to Experimental RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #24098]. Please include the string: [rt.ietf.org #24098] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue2.html Please let us know if you have any questions. Thank you. RFC Editor On Fri, Feb 19, 2010 at 07:35:24AM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'Y.1541-QOSM -- Model for Networks Using Y.1541 QoS Classes ' > as an Experimental RFC > > > This document is the product of the Next Steps in Signaling Working Group. > > The IESG contact persons are Magnus Westerlund and Lars Eggert. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-10.txt > > Technical Summary > > This draft describes a QoS-NSLP QoS model (QOSM) based on ITU-T > Recommendation Y.1541 Network QoS Classes and related signaling > requirements. Y.1541 specifies 8 classes of Network Performance > objectives, and the Y.1541-QOSM extensions include additional QSPEC > parameters and QOSM processing guidelines. > > Working Group Summary > > There have been several WGLC on the document, plus several > pre-WGLCs on the document. The editors have gotten extensive > feedback and have clarified text based upon the feedback. > > > Document Quality > > This document was reviewed by the working group chair as well > as the WG. We feel that this document is ready, and > implementors feel that the specification is implementable. > > Personnel > > WG shepherd is Jukka Manner and Responsible AD Magnus Westerlund. From wwwrun@core3.amsl.com Fri Feb 19 11:39:41 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 5F26CE06E5 for ; Fri, 19 Feb 2010 11:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxRu8IMWGx6D for ; Fri, 19 Feb 2010 11:39:41 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 3C456E06E4 for ; Fri, 19 Feb 2010 11:39:41 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 32EA928C102; Fri, 19 Feb 2010 11:37:53 -0800 (PST) Subject: [rt.ietf.org #24094] Resolved: Re: Protocol Action: 'RSVP-TE Signaling Extension For Management Plane To Control Plane LSP Handover In A GMPLS Enabled Transport Network.' to Proposed Standard From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24094 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 19 Feb 2010 11:37:53 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Fri Feb 19 11:40:15 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.4 required=5.0 tests=AWL,BAYES_00, SARE_SUB_OBFU_Q1,USER_IN_WHITELIST autolearn=no version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 42D4AE06E5 for ; Fri, 19 Feb 2010 11:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDfMRG+XdO8i for ; Fri, 19 Feb 2010 11:40:15 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 206A7E06E4 for ; Fri, 19 Feb 2010 11:40:15 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id A17783A7FFB; Fri, 19 Feb 2010 11:38:26 -0800 (PST) Subject: [rt.ietf.org #24097] Resolved: Re: Document Action: 'QoS NSLP QSPEC Template' to Experimental RFC From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24097 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 19 Feb 2010 11:38:26 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Fri Feb 19 11:40:45 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id BDB8BE06E5 for ; Fri, 19 Feb 2010 11:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFDynzPE7KXE for ; Fri, 19 Feb 2010 11:40:45 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 0A0E3E06E4 for ; Fri, 19 Feb 2010 11:40:45 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 0224E3A7D92; Fri, 19 Feb 2010 11:38:56 -0800 (PST) Subject: [rt.ietf.org #24095] Resolved: Re: Protocol Action: 'Clearance Attribute and Authority Clearance Constraints From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24095 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 19 Feb 2010 11:38:56 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Fri Feb 19 11:41:25 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 86F6EE06E5 for ; Fri, 19 Feb 2010 11:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h79Eivc6p0lH for ; Fri, 19 Feb 2010 11:41:25 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 72083E06E4 for ; Fri, 19 Feb 2010 11:41:25 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id E25BC3A7D7D; Fri, 19 Feb 2010 11:39:36 -0800 (PST) Subject: [rt.ietf.org #24098] Resolved: Re: Document Action: 'Y.1541-QOSM -- Model for Networks Using Y.1541 QoS Classes' to Experimental RFC From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24098 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 19 Feb 2010 11:39:36 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Fri Feb 19 11:42:00 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 3519CE06E5 for ; Fri, 19 Feb 2010 11:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGYZYBWL++5p for ; Fri, 19 Feb 2010 11:42:00 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 1DFD4E06E4 for ; Fri, 19 Feb 2010 11:42:00 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 14D0C3A7D2F; Fri, 19 Feb 2010 11:40:12 -0800 (PST) Subject: [rt.ietf.org #24096] Resolved: Re: Protocol Action: 'Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions' to Proposed Standard From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24096 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 19 Feb 2010 11:40:12 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Fri Feb 19 11:43:16 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-202.1 required=5.0 tests=AWL,BAYES_00, SARE_SUB_RAND_LETTRS4,SUBJECT_IN_WHITELIST,USER_IN_WHITELIST autolearn=no version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id A57CFE06E5 for ; Fri, 19 Feb 2010 11:43:16 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5if0Um4QuAVt for ; Fri, 19 Feb 2010 11:43:16 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 885ACE06E4 for ; Fri, 19 Feb 2010 11:43:16 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 7B9243A7D86; Fri, 19 Feb 2010 11:41:28 -0800 (PST) Subject: [rt.ietf.org #16291] Resolved: Re: What happened to draft-irtf-asrg-dnsbl ? From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #16291 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 19 Feb 2010 11:41:28 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Tue Feb 23 12:47:34 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 8EFAA13002A for ; Tue, 23 Feb 2010 12:47:34 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HpyuO8E-+SM for ; Tue, 23 Feb 2010 12:47:34 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 6B193130028 for ; Tue, 23 Feb 2010 12:47:34 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 0572A28C36E; Tue, 23 Feb 2010 12:45:29 -0800 (PST) Subject: [rt.ietf.org #24261] AutoReply: Re: Document Action: 'PCC-PCE Communication Requirements for Point to Multipoint Multiprotocol Label Switching Traffic Engineering (MPLS-TE)' to Informational RFC From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100223204732.GA11284@rfc-editor.org> References: <20100222173642.3987728C151@core3.amsl.com> <20100223204732.GA11284@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24261 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 23 Feb 2010 12:45:29 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'PCC-PCE Communication Requirements for Point to Multipoint Multiprotocol Label Switching Traffic Engineering (MPLS-TE)' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #24261]. Please include the string: [rt.ietf.org #24261] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue2.html Please let us know if you have any questions. Thank you. RFC Editor On Mon, Feb 22, 2010 at 09:36:42AM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'PCC-PCE Communication Requirements for Point to Multipoint > Multiprotocol Label Switching Traffic Engineering (MPLS-TE) ' > as an Informational RFC > > > This document is the product of the Path Computation Element Working Group. > > The IESG contact persons are Ross Callon and Adrian Farrel. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pce-p2mp-req-05.txt > > Technical Summary > > Generic requirements for a communication protocol between Path > Computation Clients (PCCs) and Path Computation Elements (PCEs) > are presented in "Path Computation Element (PCE) Communication > Protocol Generic Requirements". This informational document > complements the generic requirements and presents a detailed set > of PCC-PCE communication protocol requirements for point-to- > multipoint MPLS/GMPLS traffic engineering. > > Working Group Summary > > Good consensus reported with no controversy (see PROTO writeup by > JP Vasseur in the ID Tracker). > > Document Quality > > The document thas had adequate review, and has passed WG and IETF > last calls, and has been updated based on minor comments received > during IETF last call. As an informational requirements document > this is not subject to be implemented. There is ongoing work in the > PCE working group to define point to multipoint extensions to PCE. > > Personnel > > JP Vasseur is the Document Shepherd for this document. Ross Callon > is the Responsible Area Director. From wwwrun@core3.amsl.com Tue Feb 23 12:48:11 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 112D9130029 for ; Tue, 23 Feb 2010 12:48:11 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MgLiMI1Y9PT for ; Tue, 23 Feb 2010 12:48:10 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id E6057130028 for ; Tue, 23 Feb 2010 12:48:10 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 7C61828C0D9; Tue, 23 Feb 2010 12:46:04 -0800 (PST) Subject: [rt.ietf.org #24262] AutoReply: Re: Document Action: 'Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments' to Informational RFC From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100223204745.GB11284@rfc-editor.org> References: <20100223001939.50F5E28C489@core3.amsl.com> <20100223204745.GB11284@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24262 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 23 Feb 2010 12:46:04 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #24262]. Please include the string: [rt.ietf.org #24262] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue2.html Please let us know if you have any questions. Thank you. RFC Editor On Mon, Feb 22, 2010 at 04:19:39PM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'Requirements from Session Initiation Protocol (SIP) Session Border > Control (SBC) Deployments ' > as an Informational RFC > > > This document is the product of the Session Initiation Proposal Investigation Working Group. > > The IESG contact persons are Robert Sparks and Cullen Jennings. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sipping-sbc-funcs-09.txt > > Technical Summary > This documents describes functions implemented in Session > Initiation Protocol (SIP) intermediaries known as Session > Border Controllers (SBCs). The goal of this document is to > describe the commonly provided functions of SBCs. A special > focus is given to those practices that are viewed to be in > conflict with SIP architectural principles. This document > also explores the underlying requirements of network operators > that have led to the use of these functions and practices in > order to identify protocol requirements and determine whether > those requirements are satisfied by existing specifications > or additional standards work is required. > > Working Group Summary > The SIPPING WG supports the development and advancement of > this document. > > Document Quality > This document defines no new protocol elements. > The document was thoroughly reviewed within the SIPPING WG. > > Francois Audet, Spencer Dawkins and Michael Procter > provided detailed reviews during and post WGLC. From wwwrun@core3.amsl.com Tue Feb 23 12:53:43 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 11957130029 for ; Tue, 23 Feb 2010 12:53:43 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rSIUtlg9wXz for ; Tue, 23 Feb 2010 12:53:42 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id E7705130028 for ; Tue, 23 Feb 2010 12:53:42 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 957573A84EE; Tue, 23 Feb 2010 12:51:38 -0800 (PST) Subject: [rt.ietf.org #24261] Resolved: Re: Document Action: 'PCC-PCE Communication Requirements for Point to Multipoint Multiprotocol Label Switching Traffic Engineering (MPLS-TE)' to Informational RFC From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24261 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 23 Feb 2010 12:51:38 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Tue Feb 23 12:54:27 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id AB852130029 for ; Tue, 23 Feb 2010 12:54:27 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1W3ZnpD-UCRV for ; Tue, 23 Feb 2010 12:54:27 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 973BA130028 for ; Tue, 23 Feb 2010 12:54:27 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 451EF3A84EF; Tue, 23 Feb 2010 12:52:22 -0800 (PST) Subject: [rt.ietf.org #24262] Resolved: Re: Document Action: 'Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments' to Informational RFC From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24262 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 23 Feb 2010 12:52:23 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Thu Feb 25 10:16:49 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.2 required=5.0 tests=AWL,BAYES_00, J_CHICKENPOX_23,USER_IN_WHITELIST autolearn=no version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 65D7013000A for ; Thu, 25 Feb 2010 10:16:49 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEcvOBOHLCYn for ; Thu, 25 Feb 2010 10:16:49 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 467DF130009 for ; Thu, 25 Feb 2010 10:16:49 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 5B03C28C121; Thu, 25 Feb 2010 10:14:37 -0800 (PST) Subject: [rt.ietf.org #24383] AutoReply: Re: About some IAB RFCs From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100225181642.GG3737@rfc-editor.org> References: <3056.1267115776@tech-invite.com> <20100225171141.GE3737@rfc-editor.org> <20100225181642.GG3737@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24383 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 25 Feb 2010 10:14:37 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: About some IAB RFCs", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #24383]. Please include the string: [rt.ietf.org #24383] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- > Hi Joel and the Secretariat, > > The RFC Editor doesn't update the I-D tracker; the Secretariat > maintains this function. We are CC'ing them in the hopes that > they will investigate the issue you mention below. > > I note that if we search by RFC number, the results return a link to > the published RFC. However, clicking on the I-D string returns > something like the following: > > Document type: Old Internet-Draft (IAB document) > State: Expired > Intended status: - > Last updated: 2009-02-23 > Responsible AD: - > > > Thank you for notifying us of this issue. > > RFC Editor/sg > > > > On Thu, Feb 25, 2010 at 05:36:16PM +0100, Joel Repiquet wrote: > > Hi Sandy, > > I have noticed that IAB-related RFCs: 5505, 5507, 5704, 5741, 5745 > > are not taken into account by the datatracker (search with '-iab-') > > Their corresponding drafts are still listed, sometimes as > > "expired'". > > Something wrong? > > Thanks > > Jo??l > > On Mon 22/02/10 20:42 , RFC Editor rfc-editor@rfc-editor.org sent: > > Hi Russ and Joel, > > Thanks for bringing this to our attention. I see that the > > announcements for the mentioned RFCs appear on the rfc-dist list at: > > > > > > http://www.rfc-editor.org/pipermail/rfc-dist/2009-December/002454.html > > > > http://www.rfc-editor.org/pipermail/rfc-dist/2009-December/002453.html > > > > http://www.rfc-editor.org/pipermail/rfc-dist/2009-December/002452.html > > However, I don't see the mail on the ietf-announce list. I will > > look > > into why announcements are not appearing properly. > > Thanks! > > Sandy > > On Mon, Feb 22, 2010 at 02:07:42PM -0500, Russ Housley wrote: > > > I did a quick search, and I did not see an announcement for RFC > > 5729. > > > Maybe there are others. Please make sure that announcement have > > been > > > sent for al of the recently published RFCs. > > > > > > Russ > > > > > > -------- Original Message -------- > > > Subject: missing RFC announcements > > > Date: Mon, 22 Feb 2010 14:49:22 +0100 > > > From: Joel Repiquet > > > Reply-To: joel.repiquet@tech-invite.com [2] > > > To: > > > > > > > > > > > > Hi Russ > > > > > > FYI, I have noticed that RFC 5729 (ietf-dime-nai-routing) has not > > > been announced although it is present in the RFC Base from Dec > > 2009. > > > There are some other examples: RFC 5722 (6man) and RFC 5546 > > > (Calsify). In contrast, RFC 5545 also related to Calsify was > > well-announced. > > > Very likely there are some other RFCs that were not announced. > > > > > > As a result, these RFCs are not listed in the tool pages of the > > relevant > > > WGs. > > > > > > I guess this is due to the transition phase that occured at the > > end > > > of the year by the RFC Editor. > > > > > > BR > > > > > > Links: > > ------ > > [1] mailto:joel.repiquet@tech-invite.com > > [2] mailto:joel.repiquet@tech-invite.com > > [3] mailto:housley@vigilsec.com From wwwrun@core3.amsl.com Wed Mar 3 07:42:25 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-204.4 required=5.0 tests=AWL,BAYES_00, HELO_MISMATCH_ORG,HOST_MISMATCH_COM,RCVD_IN_DNSWL_MED,SUBJECT_IN_WHITELIST, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 8E8C9E06FC for ; Wed, 3 Mar 2010 07:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zfdNNgYy5en for ; Wed, 3 Mar 2010 07:42:25 -0800 (PST) Received: from mail.ietf.org (core3.amsl.com [64.170.98.32]) by rfc-editor.org (Postfix) with ESMTP id 72226E06EB for ; Wed, 3 Mar 2010 07:42:25 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 4AEDD3A8ABD; Wed, 3 Mar 2010 07:42:22 -0800 (PST) Subject: [rt.ietf.org #24560] AutoReply: Re: Pulling back draft-ietf-pkix-authorityclearanceconstraints From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100303154223.GA31334@rfc-editor.org> References: <20100303154223.GA31334@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24560 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 03 Mar 2010 07:42:23 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Pulling back draft-ietf-pkix-authorityclearanceconstraints", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #24560]. Please include the string: [rt.ietf.org #24560] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Tim, Thank for providing us with this information. We have removed the document from our queue. RFC Editor On Wed, Mar 03, 2010 at 10:41:23AM -0500, Polk, William T. wrote: > IESG Secretary and RFC Editor, > > The I-D draft-ietf-pkix-authorityclearanceconstraints needs to be pulled > back from the RFC Editor queue. Although all DISCUSSes have cleared, I have > learned that I failed to call out a normative down reference. In order to > confirm the downref, I will need to perform a targeted second IETF Last > Call. > > Please pull back the document back from the RFC Editor queue and place the > document in IESG Evaluation: AD Followup. If the downref is confirmed, I > will request a new approval announcement when the Last Call completes. > > I apologize for the mix-up. > > Thanks, > > Tim Polk From wwwrun@core3.amsl.com Wed Mar 3 09:20:27 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-204.4 required=5.0 tests=AWL,BAYES_00, HELO_MISMATCH_ORG,HOST_MISMATCH_COM,RCVD_IN_DNSWL_MED,SUBJECT_IN_WHITELIST, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id D2BB7E06F4 for ; Wed, 3 Mar 2010 09:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rr5gxl82SZlg for ; Wed, 3 Mar 2010 09:20:27 -0800 (PST) Received: from mail.ietf.org (core3.amsl.com [64.170.98.32]) by rfc-editor.org (Postfix) with ESMTP id B81BFE06F0 for ; Wed, 3 Mar 2010 09:20:27 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 82ABA3A8BD3; Wed, 3 Mar 2010 09:20:24 -0800 (PST) Subject: [rt.ietf.org #24559] Pulling back draft-ietf-pkix-authorityclearanceconstraints From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: References: Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24559 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org, william.polk@nist.gov MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 03 Mar 2010 09:20:24 -0800 Hi Tim, The state of this document has been moved back to IESG Evaluation: AD Followup, as requested. Best regards, Cindy On Wed Mar 03 07:38:10 2010, william.polk@nist.gov wrote: > IESG Secretary and RFC Editor, > > The I-D draft-ietf-pkix-authorityclearanceconstraints needs to be pulled > back from the RFC Editor queue. Although all DISCUSSes have cleared, I have > learned that I failed to call out a normative down reference. In order to > confirm the downref, I will need to perform a targeted second IETF Last > Call. > > Please pull back the document back from the RFC Editor queue and place the > document in IESG Evaluation: AD Followup. If the downref is confirmed, I > will request a new approval announcement when the Last Call completes. > > I apologize for the mix-up. > > Thanks, > > Tim Polk > From wwwrun@core3.amsl.com Wed Mar 3 09:21:01 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-204.5 required=5.0 tests=AWL,BAYES_00, HELO_MISMATCH_ORG,HOST_MISMATCH_COM,RCVD_IN_DNSWL_MED,SUBJECT_IN_WHITELIST, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 499BDE06F4 for ; Wed, 3 Mar 2010 09:21:01 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNu3hx+Elq3X for ; Wed, 3 Mar 2010 09:21:01 -0800 (PST) Received: from mail.ietf.org (core3.amsl.com [64.170.98.32]) by rfc-editor.org (Postfix) with ESMTP id 2D9FCE06F0 for ; Wed, 3 Mar 2010 09:21:01 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id EB5433A897A; Wed, 3 Mar 2010 09:20:58 -0800 (PST) Subject: [rt.ietf.org #24559] Resolved: Pulling back draft-ietf-pkix-authorityclearanceconstraints From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24559 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org, william.polk@nist.gov MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 03 Mar 2010 09:20:58 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Tue Mar 9 11:17:02 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 5918CE0743 for ; Tue, 9 Mar 2010 11:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20Q0nS2gNw3j for ; Tue, 9 Mar 2010 11:17:02 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 39F3EE0742 for ; Tue, 9 Mar 2010 11:17:02 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 17EFB3A6A4A; Tue, 9 Mar 2010 11:16:56 -0800 (PST) Subject: [rt.ietf.org #24856] AutoReply: Re: Document Action: 'Updates to Asserted Identity in the Session Initiation Protocol (SIP)' to Informational RFC From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100309191654.GL21143@rfc-editor.org> References: <20100308174458.E0AB43A6A53@core3.amsl.com> <20100309191654.GL21143@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24856 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 09 Mar 2010 11:16:57 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'Updates to Asserted Identity in the Session Initiation Protocol (SIP)' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #24856]. Please include the string: [rt.ietf.org #24856] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue2.html Please let us know if you have any questions. Thank you. RFC Editor On Mon, Mar 08, 2010 at 09:44:58AM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'Updates to Asserted Identity in the Session Initiation Protocol (SIP) ' > as an Informational RFC > > > This document is the product of the Session Initiation Proposal Investigation Working Group. > > The IESG contact persons are Cullen Jennings and Robert Sparks. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sipping-update-pai-09.txt > > Technical Summary > > SIP has a mechanism for conveying the asserted identity of the > originator of a request by means of the P-Asserted-Identity header > field. This header field is specified for use in requests using a > number of SIP methods, in particular the INVITE method. However, > RFC 3325 does not specify the insertion of this header field by a > trusted UAC, does not specify the use of P-Asserted-Identity and > P-Preferred-Identity header fields with certain SIP methods such > as UPDATE, REGISTER, MESSAGE and PUBLISH, and does not specify > how to handle an unexpected number of URIs or unexpected URI > schemes in these header fields. This document extends RFC 3325 > to cover these situations. > > Working Group Summary > The SIPPING WG supports the development and advancement of > this document. > > Document Quality > This document has no normative protocol impacts. > > The document has been thorughly reviewed in the SIPPING WG with > WG participants providing detailed reviews and comments for > the initial WG review, during each of the two WGLCs and > following the WGLCs to ensure the document was updated consistent > with WG consensus. There has been extensive face to face meeting > and WG mailing list discussions. > > Personnel > Mary Barnes is the WG chair shepherd. > > > RFC Editor Note > > > 1. Author's email address: > OLD: > john.elwell@siemens.com > > NEW: > john.elwell@siemens-enterprise.com > > 2. Abstract: > OLD: > "SIP has a mechanism for conveying the asserted identity of the originator > of a request by means of the P-Asserted-Identity header field. This header > field is specified for use in requests using a number of SIP methods, in > particular the INVITE method. However, RFC 3325 does not specify the > insertion of this header field by a trusted UAC..." > > NEW: > "The Session Initiation Protocol (SIP) has a mechanism for conveying the > identity of the originator of a request by means of the > P-Asserted-Identity and P-Preferred-Identity header fields. These header > fields are specified for use in requests using a number of SIP methods, in > particular the INVITE method. However, RFC 3325 does not specify the > insertion of the P-Asserted-Identity header field by a trusted User Agent > Client (UAC)..." > > 3. Abstract: > DELETE: > "This work is being discussed on the sipping@ietf.org mailing list." > > 4. Section 2: > OLD: > "in particular the INVITE method." > > NEW: > "in particular the INVITE method. In addition, the P-Preferred-Identity > header field can be used to indicate a preference for which identity > should be asserted when there is a choice." > > 5. Section 2: > OLD: > "RFC 3325 does not specify the insertion of the P-Asserted-Identity header > field by a UAC in the same Trust Domain as the first proxy" > > NEW: > "RFC 3325 does not specify the insertion of the P-Asserted-Identity header > field by a User Agent Client (UAC) in the same Trust Domain as the first > proxy" > > 6. Section 2: > OLD: > "at most two URIs" > > NEW: > "at most two Universal Resource Identifiers (URIs)" > > 7. Section 2: > OLD: > "to challenge a UAS" > > NEW: > "to challenge a User Agent Server (UAS)" > > 8. Section 3.1: > OLD: > "PSTN gateways" > > NEW: > "Public Switched Telephone Network (PSTN) gateways" > > 9. Section 3.1: > OLD: > "application servers (or B2BUAs)" > > NEW: > "application servers (or Back-to-Back User Agents, B2BUAs)" > > 10. Section 3.2: > OLD: > "to the peer SIP UA" > > NEW: > "to the peer SIP User Agent (UA)" > > 11. Section 3.2: > OLD: > "in requests with methods that are not provided for in RFC 3325" > > NEW: > "in requests with methods for which there is no provision in RFC 3325" > > 12. Section 4: > OLD: > "and by allowing a P-Asserted-Identity or P-Preferred-Identity header > field to appear in any request" > > NEW: > "and by allowing a P-Asserted-Identity or P-Preferred-Identity header > field to appear in any request except ACK or CANCEL" > > 13.Section 4.3: > OLD: > "If the node is within the Trust Domain" > > NEW: > "If the node is within the Trust Domain (the node having been > authenticated by some means)" > > 14. Section 4.4: > OLD: > "and represents" > > NEW: > "and is represented by" > > 15. Section 4.5: > Insert at start of first paragraph: > "An entity receiving a P-Asserted-Identity or P-Preferred-Identity header > field can expect the number of URIs and the combination of URI schemes in > the header field to be in accordance with RFC 3325, any updates to RFC > 3325, or any Spec(T) that states otherwise. " > > 16. Section 6: > OLD: > "has no standardised SIP means to authenticate the node" > > NEW: > "has no standardised SIP means to authenticate the source of the response" > > > > > > > 17. Section 6: > Delete the paragraph: > "When receiving a REGISTER request containing a P-Asserted-Identity header > field, a proxy will trust the asserted identity only if received over a > secure connection from a proxy within the Trust Domain." > > > Consider the following and make them at the RFC Editors discretion > > - Behaviour -> Behavior (i.e., American spelling) > > - ToC page 2: Acknowledgements -> Acknowledgments > > - 1 page 3: the right place to introduce common abbrevs: UAC, UAS, > URI... > > - 2 page 3: UAC and URI abbrevs should be introduced > > - 2 page 4: same for UAS > > - 2 page 4: standardised -> standardized > > - 3.1 page 4: same for PSTN (I suggest in "o PSTN gateways;") > > - 3.2 page 6: poor wording: > "with methods that are not provided for in RFC 3325 or any other RFC." > > > > - 6 page 10: standardised -> standardized > > - 7 page 10 (title): Acknowledgements -> Acknowledgments From wwwrun@core3.amsl.com Tue Mar 9 11:25:25 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id B8799E0744 for ; Tue, 9 Mar 2010 11:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGf4dd1UQuVX for ; Tue, 9 Mar 2010 11:25:25 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 96A08E0742 for ; Tue, 9 Mar 2010 11:25:25 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 8416D3A69B3; Tue, 9 Mar 2010 11:25:20 -0800 (PST) Subject: [rt.ietf.org #24857] AutoReply: Re: Document Action: 'HMAC-based Extract-and-Expand Key Derivation Function (HKDF)' to Informational RFC From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100309192522.GN21143@rfc-editor.org> References: <20100308211557.310E43A6ADF@core3.amsl.com> <20100309192522.GN21143@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24857 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 09 Mar 2010 11:25:20 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'HMAC-based Extract-and-Expand Key Derivation Function (HKDF)' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #24857]. Please include the string: [rt.ietf.org #24857] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue2.html Please let us know if you have any questions. Thank you. RFC Editor On Mon, Mar 08, 2010 at 01:15:57PM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'HMAC-based Extract-and-Expand Key Derivation Function (HKDF) ' > as an Informational RFC > > This document has been reviewed in the IETF but is not the product of an > IETF Working Group. > > The IESG contact person is Tim Polk. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-krawczyk-hkdf-01.txt > > Technical Summary > > This document specifies a simple HMAC-based key derivation function > (HKDF) which can be used as a building block in various protocols and > applications. The KDF is intended to support a wide range of > applications and requirements, and is conservative in its use of > cryptographic hash functions. > > Working Group Summary > > This document was not the product of any working group. > However, this KDF is already specified in several standards > track RFCs produced by IETF wgs, including IKEv2 (RFC 4306), > PANA (RFC 5191) and EAP-AKA (RFC 5448). > > In addition, the cfrg reviewed this document at the request > of the sponsoring AD. The discussion was lively, but focused > on additional functionality that could be considered. The cfrg > did not identify any changes that were required. > > Document Quality > > This KDF is widely implemented and used in the context of > specific IETF protocols, especially those that rely on IKEv2. > > Personnel > > Tim Polk is the Document Shepherd for this document and the > Responsible Area Director. > > RFC Editor Note > > Please make the following substitutions: > > Section 1: > OLD > It is not intended as a call to change existing protocols. > NEW: > It is not intended as a call to change existing protocols, > and does not change or update existing specifications using > this KDF. > > Section 2.2: > OLD: > PRK = HKDF-Extract(salt, IKM) > NEW > HKDF-Extract(salt, IKM) -> PRK > > Section 2.3: > OLD > OKM = HKDF-Expand(PRK, info, L) > NEW: > HKDF-Expand(PRK, info, L) -> OKM From wwwrun@core3.amsl.com Tue Mar 9 11:32:29 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 269E2E0743 for ; Tue, 9 Mar 2010 11:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6V6XAwnTNreG for ; Tue, 9 Mar 2010 11:32:29 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 0B9F8E0742 for ; Tue, 9 Mar 2010 11:32:29 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 0382E3A6A13; Tue, 9 Mar 2010 11:32:23 -0800 (PST) Subject: [rt.ietf.org #24858] AutoReply: Re: Protocol Action: 'Generalized Multi-Protocol Label Switching (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)' to Proposed Standard From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100309193227.GO21143@rfc-editor.org> References: <20100308211337.09D953A69BE@core3.amsl.com> <20100309193227.GO21143@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24858 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 09 Mar 2010 11:32:23 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Generalized Multi-Protocol Label Switching (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #24858]. Please include the string: [rt.ietf.org #24858] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue2.html Please let us know if you have any questions. Thank you. RFC Editor On Mon, Mar 08, 2010 at 01:13:36PM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'Generalized Multi-Protocol Label Switching (GMPLS) Protocol Extensions > for Multi-Layer and Multi-Region Networks (MLN/MRN) ' > as a Proposed Standard > > > This document is the product of the Common Control and Measurement Plane Working Group. > > The IESG contact persons are Adrian Farrel and Ross Callon. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-extensions-12.txt > > Technical Summary > > This document extends GMPLS routing and signaling to support the > operation of GMPLS Multi-Layer/Multi-Region Networks. A network > comprised of multiple switching types (e.g. PSC and TDM) controlled > by a single GMPLS control plane instance is called a Multi-Region > Network (MRN). A network comprising transport nodes participating in > different data plane switching layers controlled by a single GMPLS > control plane instance is called a Multi-Layer Network (MLN). This > document defines GMPLS RSVP, OSPF and IS-IS to cover GMPLS MLN/MRN > requirements. > > Working Group Summary > > This document received much attention and discussion in its early > revisions. The document has been largely stable for quite some time, > mainly needing revisions as part of the publication process. > > Document Quality > > There have been no public statements related to intent to implement, > but portions of the extensions are now being used as part of the GMPLS > tool set and are (at least) expected to implemented in those contexts. > > Personnel > > Lou Berger (lberger@labn.net) is the Document Shepherd. > Adrian Farrel (adrian.farrel@huawei.com) is the Responsible AD > > RFC Editor Note > > RFC Editor - we suggest that you treat this I-D as part of a cluster > including the following five documents. > > draft-ietf-ccamp-ethernet-traffic-parameters > draft-ietf-ccamp-gmpls-dcsc-channel-ext > draft-ietf-ccamp-gmpls-ether-svcs > draft-ietf-ccamp-gmpls-mef-uni > draft-ietf-ccamp-gmpls-mln-extensions > --- > Section 1 > s/TDM switching (TDM)/Time-Division Multiplexing Switching (TDM)/ > --- > Section 5.1 final paragraph > s/CALL ATTRIBUTES/CALL_ATTRIBUTES/ > --- > Section 5.1.5 paragraph 1 > s/the Attributes Flags/the Call Attributes Flags/ > --- > > IANA Note > > IANA - Please note that this I-D creates a registry which is > also used by draft-ietf-ccamp-gmpls-ether-svcs which is also > in the pipeline From wwwrun@core3.amsl.com Tue Mar 9 11:36:32 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id EE5CDE0745 for ; Tue, 9 Mar 2010 11:36:32 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXtBvQm3jvJi for ; Tue, 9 Mar 2010 11:36:32 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id D5C8EE0742 for ; Tue, 9 Mar 2010 11:36:32 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id CC1A83A69E7; Tue, 9 Mar 2010 11:36:27 -0800 (PST) Subject: [rt.ietf.org #24859] AutoReply: Re: Protocol Action: 'The SDP (Session Description Protocol) Grouping Framework' to Proposed Standard From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100309193630.GP21143@rfc-editor.org> References: <20100308204705.7521F3A6A05@core3.amsl.com> <20100309193630.GP21143@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24859 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 09 Mar 2010 11:36:27 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'The SDP (Session Description Protocol) Grouping Framework' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #24859]. Please include the string: [rt.ietf.org #24859] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue2.html Please let us know if you have any questions. Thank you. RFC Editor On Mon, Mar 08, 2010 at 12:47:05PM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'The SDP (Session Description Protocol) Grouping Framework ' > as a Proposed Standard > > > This document is the product of the Multiparty Multimedia Session Control Working Group. > > The IESG contact persons are Cullen Jennings and Robert Sparks. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc3388bis-04.txt > > Working Group summary: > > The MMUSIC WG has firm consenses on publishing this document > as Proposed Standard. > > Document quality: > > The document has received ample review and gone through two > working group last calls. It is technically sound and stable. > > Personnel: > > The document shepherd is Joerg Ott, the responsible AD is > Cullen Jennings. From wwwrun@core3.amsl.com Tue Mar 9 11:42:07 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 2C899E0745 for ; Tue, 9 Mar 2010 11:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBCaTKHok93T for ; Tue, 9 Mar 2010 11:42:07 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 091C5E0731 for ; Tue, 9 Mar 2010 11:42:07 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id EEF7D3A69D8; Tue, 9 Mar 2010 11:42:01 -0800 (PST) Subject: [rt.ietf.org #24860] AutoReply: Re: Protocol Action: 'Diameter Quality of Service Application' to Proposed Standard From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100309194202.GQ21143@rfc-editor.org> References: <20100308154132.E1D7A3A69EE@core3.amsl.com> <20100309194202.GQ21143@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24860 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 09 Mar 2010 11:42:01 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Diameter Quality of Service Application' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #24860]. Please include the string: [rt.ietf.org #24860] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue2.html Please let us know if you have any questions. Thank you. RFC Editor On Mon, Mar 08, 2010 at 07:41:32AM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'Diameter Quality of Service Application ' > as a Proposed Standard > > > This document is the product of the Diameter Maintenance and Extensions Working Group. > > The IESG contact persons are Dan Romascanu and Ron Bonica. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-15.txt > > Technical Summary > > The document specifies a framework, messages and AVPs for > performing QoS authorization operations. It defines a QoS Diameter > application that allows network elements (QoS aware routers) to > interact with Diameter servers to authorize QoS request. It > has been designed to operate in both 'Push' or 'Pull' mode > where QoS authorization state is either sent to the network > element pro-actively (Push) or the network element directly > request QoS authorization from the Diameter server. > > A set of commands and AVPs has been defined to support both > operating modes. A supplemental state machine that augments > the Diameter base protocol (RFC3588) state machine has also been > defined to cleanly support Push mode operations. The document > also describes QoS authorization session establishment as well > as re-authorization. It provides examples and call flows that > describes how QoS authorization can be used other applications > (e.g. NSLP, SIP). > > Working Group Summary > > There was consensus in the WG to publish the document. > > Document Quality > > The document has been sent for review to NSIS and relevant QoS folks. > > > > This document defines a core component of a Network Operators QoS > architecture and thus have gone through a long review process > both within DIME WG and outside of it. It has also traversed > several re-start iteration before its current acceptable state. > > > Personnel > > Victor Fajardo is the document shepherd for this document. Dan > Romascanu is the shepherding AD. From wwwrun@core3.amsl.com Tue Mar 9 11:45:09 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 4F571E0745 for ; Tue, 9 Mar 2010 11:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XR7jEhR-s8Mr for ; Tue, 9 Mar 2010 11:45:09 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 3287BE0731 for ; Tue, 9 Mar 2010 11:45:09 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 2ABAF3A6A30; Tue, 9 Mar 2010 11:45:03 -0800 (PST) Subject: [rt.ietf.org #24861] AutoReply: Re: Document Action: 'TFTP Server Address Option for DHCPv4' to Informational RFC From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100309194507.GR21143@rfc-editor.org> References: <20100308152744.E6FA03A69F4@core3.amsl.com> <20100309194507.GR21143@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24861 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 09 Mar 2010 11:45:04 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'TFTP Server Address Option for DHCPv4' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #24861]. Please include the string: [rt.ietf.org #24861] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue2.html Please let us know if you have any questions. Thank you. RFC Editor On Mon, Mar 08, 2010 at 07:27:44AM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'TFTP Server Address Option for DHCPv4 ' > as an Informational RFC > > This document has been reviewed in the IETF but is not the product of an > IETF Working Group. > > The IESG contact person is Jari Arkko. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-raj-dhc-tftp-addr-option-06.txt > > Technical Summary > > This memo documents existing usage for the "VoIP Configuration Server > Address Option" (previously known as the "TFTP Server IP Address > Option"). The option number currently in use is 150. This memo > documents the current usage of the option in agreement with > [RFC3942], which declares that any pre-existing usages of option > numbers in the range 128 - 223 should be documented and the working > group will try to officially assign those numbers to those options. > > Working Group Summary > > There was nothing controversial about this document. > > Document Quality > > It is believed that at least one DHCP server and client > implementation support the option specified in this document. > Further, it is believed that to some extent this > option is in use in some deployments of VoIP devices. > > Review was was performed with key members of the dhc WG. No > special reviews were performed or required. > > Personnel > > Shepherd: John Jason Brzozowski > AD: Jari Arkko > IANA: N/A > > RFC Editor Note > > Please change the title of the document as follows: > > OLD: > VoIP Configuration Server Address Option > NEW: > VoIP Configuration Server Address Option for DHCPv4 > > Please add this to the end of the abstract: > > NEW: > The option is defined for DHCPv4 and works only with > IPv4 addresses. > > Please change this in Section 5: > > OLD: > If this is a concern, then DHCP Authentication may be used. > NEW: > If this is a concern, then DHCP Authentication may be used, but > even secure delivery of an address over DHCP does not protect > the subsequent insecure download over TFTP. From wwwrun@core3.amsl.com Tue Mar 9 12:09:47 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 21847E0731 for ; Tue, 9 Mar 2010 12:09:47 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fo2Qz02piCcY for ; Tue, 9 Mar 2010 12:09:47 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 0138AE0702 for ; Tue, 9 Mar 2010 12:09:46 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id E45143A6A30; Tue, 9 Mar 2010 12:09:41 -0800 (PST) Subject: [rt.ietf.org #24861] Resolved: Re: Document Action: 'TFTP Server Address Option for DHCPv4' to Informational RFC From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24861 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 09 Mar 2010 12:09:41 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Tue Mar 9 12:10:32 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id A0A60E0742 for ; Tue, 9 Mar 2010 12:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RubSLmk7fbbC for ; Tue, 9 Mar 2010 12:10:32 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 89050E0702 for ; Tue, 9 Mar 2010 12:10:32 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 773A93A68EE; Tue, 9 Mar 2010 12:10:27 -0800 (PST) Subject: [rt.ietf.org #24856] Resolved: Re: Document Action: 'Updates to Asserted Identity in the Session Initiation Protocol (SIP)' to Informational RFC From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24856 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 09 Mar 2010 12:10:27 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Tue Mar 9 12:11:33 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 724E5E0731 for ; Tue, 9 Mar 2010 12:11:33 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iV9GpDchbYST for ; Tue, 9 Mar 2010 12:11:33 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 57AE5E0702 for ; Tue, 9 Mar 2010 12:11:33 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 4E99F3A6870; Tue, 9 Mar 2010 12:11:28 -0800 (PST) Subject: [rt.ietf.org #24858] Resolved: Re: Protocol Action: 'Generalized Multi-Protocol Label Switching (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)' to Proposed Standard From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24858 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 09 Mar 2010 12:11:28 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Tue Mar 9 12:12:50 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id BBD98E0731 for ; Tue, 9 Mar 2010 12:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rhmM6KRyepJ for ; Tue, 9 Mar 2010 12:12:50 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id A2FFDE0702 for ; Tue, 9 Mar 2010 12:12:50 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 811C93A6A37; Tue, 9 Mar 2010 12:12:45 -0800 (PST) Subject: [rt.ietf.org #24857] Resolved: Re: Document Action: 'HMAC-based Extract-and-Expand Key Derivation Function (HKDF)' to Informational RFC From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24857 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 09 Mar 2010 12:12:45 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Tue Mar 9 12:24:35 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 09E9DE0731 for ; Tue, 9 Mar 2010 12:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wk4ayOjvyVEe for ; Tue, 9 Mar 2010 12:24:34 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id E4E10E0702 for ; Tue, 9 Mar 2010 12:24:34 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id D428B3A6A22; Tue, 9 Mar 2010 12:24:29 -0800 (PST) Subject: [rt.ietf.org #24859] Resolved: Re: Protocol Action: 'The SDP (Session Description Protocol) Grouping Framework' to Proposed Standard From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24859 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 09 Mar 2010 12:24:29 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Tue Mar 9 12:25:34 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id CC0F8E0742 for ; Tue, 9 Mar 2010 12:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gX-NxUFRupgT for ; Tue, 9 Mar 2010 12:25:34 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id B1750E0731 for ; Tue, 9 Mar 2010 12:25:34 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id A09DE3A69B0; Tue, 9 Mar 2010 12:25:29 -0800 (PST) Subject: [rt.ietf.org #24860] Resolved: Re: Protocol Action: 'Diameter Quality of Service Application' to Proposed Standard From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24860 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 09 Mar 2010 12:25:29 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Fri Mar 12 11:33:46 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 980CAE0732 for ; Fri, 12 Mar 2010 11:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTkf+4-K7wiD for ; Fri, 12 Mar 2010 11:33:46 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 79111E0720 for ; Fri, 12 Mar 2010 11:33:46 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id E746C3A690A; Fri, 12 Mar 2010 11:33:39 -0800 (PST) Subject: [rt.ietf.org #24989] AutoReply: Re: Protocol Action: 'Requirements for OAM in MPLS Transport Networks' to Proposed Standard From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100312193343.GA21814@rfc-editor.org> References: <20100312144731.D4B953A6D24@core3.amsl.com> <20100312193343.GA21814@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24989 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 12 Mar 2010 11:33:39 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Requirements for OAM in MPLS Transport Networks' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #24989]. Please include the string: [rt.ietf.org #24989] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- received. On Fri, Mar 12, 2010 at 06:47:31AM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'Requirements for OAM in MPLS Transport Networks ' > as a Proposed Standard > > > This document is the product of the Multiprotocol Label Switching Working Group. > > The IESG contact persons are Adrian Farrel and Ross Callon. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requirements-06.txt > > Technical Summary > > This document lists architectural and functional requirements for the > Operations, Administration and Maintenance of the MPLS Transport > Profile. These requirements apply to pseudowires, Label Switched > Paths, and MPLS-TP Sections. > > Working Group Summary > > The document is part of the MPLS-TP project, the cooperation > between IETF and ITU-T to specify an MPLS transport profile. > The working group has consensus on the document, and the ITU-T > has indicated that it supports the publication > > The ITU-T has one outstanding issue on which they could not reach > consensus: there will a continued discussion on the requirements > for OAM interworking/translation, and further requirements may be > subsequently brought to the IETF in a new I-D. > > The document has been put on the standards track to resolve issues > around how the ITU-T references IETF documents. > > Document Quality > > The document is a requirements specification and will mainly > be used as input to the OAM solutions specifications that will be > published shortly. > > Personnel > > Loa Andersson (loa@pi.nu) is the Document Shepherd. > Adrian Farrel (adrian.farrel@huawei.com) is the Responsible AD. From wwwrun@core3.amsl.com Fri Mar 12 11:34:02 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 6BD2AE0732 for ; Fri, 12 Mar 2010 11:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8j9IsdJSeosN for ; Fri, 12 Mar 2010 11:34:02 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 53066E0720 for ; Fri, 12 Mar 2010 11:34:02 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id C16663A690A; Fri, 12 Mar 2010 11:33:55 -0800 (PST) Subject: [rt.ietf.org #24990] AutoReply: Re: Protocol Action: 'Requirements for OAM in MPLS Transport Networks' to Proposed Standard From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100312193400.GB21814@rfc-editor.org> References: <20100312144731.D4B953A6D24@core3.amsl.com> <20100312193400.GB21814@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24990 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 12 Mar 2010 11:33:55 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Requirements for OAM in MPLS Transport Networks' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #24990]. Please include the string: [rt.ietf.org #24990] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue2.html Please let us know if you have any questions. Thank you. RFC Editor On Fri, Mar 12, 2010 at 06:47:31AM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'Requirements for OAM in MPLS Transport Networks ' > as a Proposed Standard > > > This document is the product of the Multiprotocol Label Switching Working Group. > > The IESG contact persons are Adrian Farrel and Ross Callon. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requirements-06.txt > > Technical Summary > > This document lists architectural and functional requirements for the > Operations, Administration and Maintenance of the MPLS Transport > Profile. These requirements apply to pseudowires, Label Switched > Paths, and MPLS-TP Sections. > > Working Group Summary > > The document is part of the MPLS-TP project, the cooperation > between IETF and ITU-T to specify an MPLS transport profile. > The working group has consensus on the document, and the ITU-T > has indicated that it supports the publication > > The ITU-T has one outstanding issue on which they could not reach > consensus: there will a continued discussion on the requirements > for OAM interworking/translation, and further requirements may be > subsequently brought to the IETF in a new I-D. > > The document has been put on the standards track to resolve issues > around how the ITU-T references IETF documents. > > Document Quality > > The document is a requirements specification and will mainly > be used as input to the OAM solutions specifications that will be > published shortly. > > Personnel > > Loa Andersson (loa@pi.nu) is the Document Shepherd. > Adrian Farrel (adrian.farrel@huawei.com) is the Responsible AD. From wwwrun@core3.amsl.com Fri Mar 12 11:44:14 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id E4985E0732 for ; Fri, 12 Mar 2010 11:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nss-gVM68-WR for ; Fri, 12 Mar 2010 11:44:14 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id CCA89E0720 for ; Fri, 12 Mar 2010 11:44:14 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 45E613A6953; Fri, 12 Mar 2010 11:44:07 -0800 (PST) Subject: [rt.ietf.org #24989] Resolved: Re: Protocol Action: 'Requirements for OAM in MPLS Transport Networks' to Proposed Standard From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24989 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 12 Mar 2010 11:44:08 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Fri Mar 12 11:45:10 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 5BF1DE0732 for ; Fri, 12 Mar 2010 11:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uPERdNQCevK for ; Fri, 12 Mar 2010 11:45:10 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 45E2AE0720 for ; Fri, 12 Mar 2010 11:45:10 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id B32243A6978; Fri, 12 Mar 2010 11:45:03 -0800 (PST) Subject: [rt.ietf.org #24990] Resolved: Re: Protocol Action: 'Requirements for OAM in MPLS Transport Networks' to Proposed Standard From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24990 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 12 Mar 2010 11:45:03 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Fri Mar 12 12:31:15 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 92796E0732 for ; Fri, 12 Mar 2010 12:31:15 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yjc-iM4db3Ac for ; Fri, 12 Mar 2010 12:31:15 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 734E6E0720 for ; Fri, 12 Mar 2010 12:31:15 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id DA42C3A696A; Fri, 12 Mar 2010 12:31:08 -0800 (PST) Subject: [rt.ietf.org #24992] AutoReply: Re: Protocol Action: 'DSCP for Capacity-Admitted Traffic' to Proposed Standard From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100312203053.GD21814@rfc-editor.org> References: <20100312161946.D1E623A6BD8@core3.amsl.com> <20100312203053.GD21814@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24992 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 12 Mar 2010 12:31:08 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'DSCP for Capacity-Admitted Traffic' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #24992]. Please include the string: [rt.ietf.org #24992] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue2.html Please let us know if you have any questions. Thank you. RFC Editor On Fri, Mar 12, 2010 at 08:19:46AM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'DSCP for Capacity-Admitted Traffic ' > as a Proposed Standard > > > This document is the product of the Transport Area Working Group. > > The IESG contact persons are Magnus Westerlund and Lars Eggert. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-admitted-realtime-dscp-07.txt > > Technical Summary > > This document requests one Differentiated Services Code Point (DSCP) > from the Internet Assigned Numbers Authority (IANA) for real-time > traffic classes similar to voice conforming to the Expedited > Forwarding Per Hop Behavior, and admitted using a call admission > procedure involving authentication, authorization, and capacity > admission. > > This document also recommends that certain classes of video traffic > described in RFC 4594 and which have similar requirements be changed > to require admission using a Call Admission Control (CAC) procedure > involving authentication, authorization, and capacity admission. > > Working Group Summary > > There was strong consensus from the one that involved themselves > with this document. > > Document Quality > > There has been reasonable amount of review of this document. There > has been several that indicated interest or need for this new DSCP. > > Personel > > Magnus Westerlund was both WG shepherd and responsible AD. From wwwrun@core3.amsl.com Fri Mar 12 12:31:16 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 61EB7E0732 for ; Fri, 12 Mar 2010 12:31:16 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJSDZs-IP1yt for ; Fri, 12 Mar 2010 12:31:16 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 48366E0720 for ; Fri, 12 Mar 2010 12:31:16 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id A78493A6953; Fri, 12 Mar 2010 12:31:09 -0800 (PST) Subject: [rt.ietf.org #24993] AutoReply: Re: Document Action: 'DomainKeys Identified Mail (DKIM) Development, Deployment and Operations' to Informational RFC From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100312203059.GE21814@rfc-editor.org> References: <20100312162203.EA2BE3A6D07@core3.amsl.com> <20100312203059.GE21814@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24993 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 12 Mar 2010 12:31:09 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'DomainKeys Identified Mail (DKIM) Development, Deployment and Operations' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #24993]. Please include the string: [rt.ietf.org #24993] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue2.html Please let us know if you have any questions. Thank you. RFC Editor On Fri, Mar 12, 2010 at 08:22:03AM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'DomainKeys Identified Mail (DKIM) Development, Deployment and > Operations ' > as an Informational RFC > > > This document is the product of the Domain Keys Identified Mail Working Group. > > The IESG contact persons are Pasi Eronen and Tim Polk. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dkim-deployment-11.txt > > Technical Summary > > This document provides implementation, deployment, operational and > migration considerations for DKIM. > > Working Group Summary > > There are several areas where the document could provide more > guidance, but the WG decided that more field experience is needed > before we know what the guidance should be. > > Document Quality > > This document gives guidance on implementation based on experience > of participants and vendors who have already implemented the DKIM > protocols. The document has been well reviewed by participants > with implementation/deployment experience. > > Personnel > > The document shepherd is Barry Leiba, and the responsible area > director is Pasi Eronen. > > RFC Editor Note > > Please add a new paragraph to Section 1, after the first paragraph: > > The reader is encouraged to read the DKIM Service Overview document > [RFC5585] before this document. More detailed guidance about DKIM > and ADSP can also be found in the protocol specifications [RFC4871], > [RFC5617], and [RFC5672]. From wwwrun@core3.amsl.com Fri Mar 12 12:31:24 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 01B49E0732 for ; Fri, 12 Mar 2010 12:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcZzMKMko5PC for ; Fri, 12 Mar 2010 12:31:23 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id D9DBFE0720 for ; Fri, 12 Mar 2010 12:31:23 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 4FE8E3A6953; Fri, 12 Mar 2010 12:31:17 -0800 (PST) Subject: [rt.ietf.org #24994] AutoReply: Re: Document Action: 'The application/pkix-attr-cert Media Type for Attribute Certificates' to Informational RFC From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100312203114.GF21814@rfc-editor.org> References: <20100312162438.7958E3A6B41@core3.amsl.com> <20100312203114.GF21814@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24994 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 12 Mar 2010 12:31:17 -0800 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'The application/pkix-attr-cert Media Type for Attribute Certificates' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #24994]. Please include the string: [rt.ietf.org #24994] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue2.html Please let us know if you have any questions. Thank you. RFC Editor On Fri, Mar 12, 2010 at 08:24:38AM -0800, iesg-secretary wrote: > The IESG has approved the following document: > > - 'The application/pkix-attr-cert Media Type for Attribute Certificates ' > as an Informational RFC > > > This document is the product of the Public-Key Infrastructure (X.509) Working Group. > > The IESG contact persons are Tim Polk and Pasi Eronen. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pkix-attr-cert-mime-type-03.txt > > Technical Summary > > This document defines a MIME content type (application/pkix-attr-cert) > for carrying an attribute certificate [RFC 3281]. This content type is > needed to enable transport of attribute (as opposed to public-key) > certificates) via protocols that make use of MIME encoding, e.g., HTTP. > > Working Group Summary > > The working group expressed consensus to approve this document as an > informational RFC. > > Document Quality > > The document is very brief (only 4 pages, including  all, of the > boilerplate) and well-written. > > Personnel > > Steve Kent is the Document Shepherd; Tim Polk is the > Responsible Area Director. > > RFC Editor Note > > Please make the following changes: > > In Section 14.1: > > OLD > [RFC3281] S. Farrell, S., and R. Housley, "An Internet Attribute > Certificate Profile for Authorization", RFC 3281, > April 2002. > NEW > [RFC5755] Farrell, S., R. Housley, and S. Turner, "An Internet > Attribute Certificate Profile for Authorization", RFC 5755, > > January 2010. > > Please make the following two global substitutions: > s/RFC 3281/RFC 5755/ > s/[RFC3281]/[RFC5755]/ From wwwrun@core3.amsl.com Fri Mar 12 12:41:13 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id D41FDE0732 for ; Fri, 12 Mar 2010 12:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axeoF-NAEwPv for ; Fri, 12 Mar 2010 12:41:13 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id B38FAE0720 for ; Fri, 12 Mar 2010 12:41:13 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 1E13F3A6901; Fri, 12 Mar 2010 12:41:06 -0800 (PST) Subject: [rt.ietf.org #24994] Resolved: Re: Document Action: 'The application/pkix-attr-cert Media Type for Attribute Certificates' to Informational RFC From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24994 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 12 Mar 2010 12:41:07 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Fri Mar 12 12:41:40 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 47A3CE0732 for ; Fri, 12 Mar 2010 12:41:40 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LK2MijBX-Sim for ; Fri, 12 Mar 2010 12:41:40 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 313B6E0720 for ; Fri, 12 Mar 2010 12:41:40 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 978873A68C9; Fri, 12 Mar 2010 12:41:33 -0800 (PST) Subject: [rt.ietf.org #24992] Resolved: Re: Protocol Action: 'DSCP for Capacity-Admitted Traffic' to Proposed Standard From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24992 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 12 Mar 2010 12:41:33 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Fri Mar 12 12:42:08 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 16F60E0732 for ; Fri, 12 Mar 2010 12:42:08 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id outMCeGkSqta for ; Fri, 12 Mar 2010 12:42:08 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 02A87E0720 for ; Fri, 12 Mar 2010 12:42:08 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 689D13A6901; Fri, 12 Mar 2010 12:42:01 -0800 (PST) Subject: [rt.ietf.org #24993] Resolved: Re: Document Action: 'DomainKeys Identified Mail (DKIM) Development, Deployment and Operations' to Informational RFC From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24993 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 12 Mar 2010 12:42:01 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Thu Mar 18 07:54:17 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id B65B8E075B for ; Thu, 18 Mar 2010 07:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMyot8hmQERc for ; Thu, 18 Mar 2010 07:54:17 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 9CC89E0735 for ; Thu, 18 Mar 2010 07:54:17 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 7A2E03A6C2F; Thu, 18 Mar 2010 07:54:05 -0700 (PDT) Subject: [rt.ietf.org #25236] AutoReply: Re: Document Action: 'Building Automation Routing Requirements in Low Power and Lossy Networks' to Informational RFC From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100318145415.GC23463@rfc-editor.org> References: <20100316150949.D49173A6B56@core3.amsl.com> <20100318145415.GC23463@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #25236 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 18 Mar 2010 07:54:05 -0700 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'Building Automation Routing Requirements in Low Power and Lossy Networks' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #25236]. Please include the string: [rt.ietf.org #25236] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue2.html Please let us know if you have any questions. Thank you. RFC Editor On Tue, Mar 16, 2010 at 08:09:49AM -0700, iesg-secretary wrote: > The IESG has approved the following document: > > - 'Building Automation Routing Requirements in Low Power and Lossy > Networks ' > as an Informational RFC > > > This document is the product of the Routing Over Low power and Lossy networks Working Group. > > The IESG contact persons are Adrian Farrel and Ross Callon. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-building-routing-reqs-09.txt > > Technical Summary > > The Routing Over Low power and Lossy network (ROLL) Working Group has > been chartered to work on routing solutions for Low Power and Lossy > networks (LLN) in various markets: Industrial, Commercial > (Building), Home and Urban networks. Pursuant to this effort, this > document defines the IPv6 routing requirements for building automation. > > Commercial buildings have been fitted with pneumatic and subsequently > electronic communication pathways connecting sensors to their > controllers for over one hundred years. Recent economic and technical > advances in wireless communication allow facilities to increasingly > utilize a wireless solution in lieu of a wired solution; thereby > reducing installation costs while maintaining highly reliant > communication. > > The cost benefits and ease of installation of wireless sensors allow > customers to further instrument their facilities with additional > sensors; providing tighter control while yielding increased energy > savings. > > IPv6 is beoming the accepted technology for use in such environments, > but that means that the IP packets must be routed in LLNs. This > document examines the specific routing requirements imposed by > building automation applications. > > Working Group Summary > > No controversy. > > Document Quality > > The I-D is informational and specifies IPv6 routing requirements. > The I-D has been revised to take advantage of the comments made on > previous ROLL routing requirement drafts. > > Personnel > > JP Vasseur is the Document Shepherd. > Adrian Farrel is the Responsible Area Director. > > RFC Editor Note > > Section 5.8 - New first paragraph > > This section sets out specific requirements that are placed on any > protocols that are developed or used in the ROLL building environment > in order to ensure adequate security and retain suitable flexibility > of use and function of the protocol. > > --- > > Section 5.8 > OLD > FMS systems are typically highly configurable in the field and hence > the security policy is most often dictated by the type of building to > which the FMS is being installed. Single tenant owner occupied > office buildings installing lighting or HVAC control are candidates > for implementing low or even no security on the LLN. Antithetically, > military or pharmaceutical facilities require strong security > policies. As noted in the installation procedures, security policies > must be facile to allow for no security policy during the > installation phase (prior to building occupancy), yet easily raise > the security level network wide during the commissioning phase of the > system. > NEW > FMS systems are typically highly configurable in the field and hence > the security policy is most often dictated by the type of building to > which the FMS is being installed. Single tenant owner occupied > office buildings installing lighting or HVAC control are candidates > for implementing a low level of security on the LLN especially when > the LLN is not connected to an external network. Antithetically, > military or pharmaceutical facilities require strong security > policies. As noted in the installation procedures described in > Sections 3.3 and 5.2, security policies MUST support dynamic > configuration to allow for a low level of security during the > installation phase (prior to building occupancy when it may be > appropriate to use only diagnostic levels of security), yet to make > it possible easily raise the security level network wide during the > commissioning phase of the system. From wwwrun@core3.amsl.com Thu Mar 18 07:56:24 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 790B5E075B for ; Thu, 18 Mar 2010 07:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gO3OF67MJyEP for ; Thu, 18 Mar 2010 07:56:24 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 58583E0735 for ; Thu, 18 Mar 2010 07:56:24 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 563593A6C3A; Thu, 18 Mar 2010 07:56:12 -0700 (PDT) Subject: [rt.ietf.org #25237] AutoReply: Re: Protocol Action: 'Resource ReSerVation Protocol (RSVP) Extensions for Admission Priority' to Proposed Standard From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100318145618.GE23463@rfc-editor.org> References: <20100317140621.CAEA328B56A@core3.amsl.com> <20100318145618.GE23463@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #25237 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 18 Mar 2010 07:56:12 -0700 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Resource ReSerVation Protocol (RSVP) Extensions for Admission Priority' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #25237]. Please include the string: [rt.ietf.org #25237] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue2.html Please let us know if you have any questions. Thank you. RFC Editor On Wed, Mar 17, 2010 at 07:06:21AM -0700, iesg-secretary wrote: > The IESG has approved the following document: > > - 'Resource ReSerVation Protocol (RSVP) Extensions for Admission Priority ' > as a Proposed Standard > > > This document is the product of the Transport Area Working Group. > > The IESG contact persons are Magnus Westerlund and Lars Eggert. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-15.txt > > Technical Summary > > Some applications require the ability to provide an elevated > probability of session establishment to specific sessions in times of > network congestion. When supported over the Internet Protocol suite, > this may be facilitated through a network layer admission control > solution that supports prioritized access to resources (e.g., > bandwidth). These resources may be explicitly set aside for > prioritized sessions, or may be shared with other sessions. This > document specifies extensions to the Resource reSerVation Protocol > (RSVP) that can be used to support such an admission priority > capability at the network layer. > > Working Group Summary > > There is WG consensus for publishing this document. > > Document Quality > > This document has been well reviewed by the WG. It now includes changes > after IESG feedback and updates after further discussion in TSVWG. > > Personnel > > Magnus Westerlund was previously the WG shepherd of an earlier > submission and is now the responsible AD. > > RFC Editor Note > > Section 9. Reference section: > Please move reference [I-D.rahman-rtg-router-alert-considerations] from > the informative section to the normative section. From wwwrun@core3.amsl.com Thu Mar 18 09:06:23 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id E7DF6E0754 for ; Thu, 18 Mar 2010 09:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsPEPO9TFmlv for ; Thu, 18 Mar 2010 09:06:23 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id D0651E0734 for ; Thu, 18 Mar 2010 09:06:23 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id B918C3A6C94; Thu, 18 Mar 2010 09:06:11 -0700 (PDT) Subject: [rt.ietf.org #25236] Resolved: Re: Document Action: 'Building Automation Routing Requirements in Low Power and Lossy Networks' to Informational RFC From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #25236 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 18 Mar 2010 09:06:11 -0700 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Thu Mar 18 09:07:11 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 04603E0735 for ; Thu, 18 Mar 2010 09:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1IR3L3LBcfe for ; Thu, 18 Mar 2010 09:07:10 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id E2D7EE0734 for ; Thu, 18 Mar 2010 09:07:10 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id C65D73A6C90; Thu, 18 Mar 2010 09:06:58 -0700 (PDT) Subject: [rt.ietf.org #25237] Resolved: Re: Protocol Action: 'Resource ReSerVation Protocol (RSVP) Extensions for Admission Priority' to Proposed Standard From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #25237 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 18 Mar 2010 09:06:58 -0700 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Sun Mar 21 10:56:23 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id EC9E2E0763 for ; Sun, 21 Mar 2010 10:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjSV3opt3qKb for ; Sun, 21 Mar 2010 10:56:23 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id CF5F8E0762 for ; Sun, 21 Mar 2010 10:56:23 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 293D23A685A; Sun, 21 Mar 2010 10:56:06 -0700 (PDT) Subject: [rt.ietf.org #25331] AutoReply: Re: Document Action: 'New ASN.1 Modules for PKIX' to Informational RFC From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100321175621.GB13391@rfc-editor.org> References: <20100321035425.901C13A69C1@core3.amsl.com> <20100321175621.GB13391@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #25331 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Sun, 21 Mar 2010 10:56:07 -0700 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'New ASN.1 Modules for PKIX' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #25331]. Please include the string: [rt.ietf.org #25331] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue2.html Please let us know if you have any questions. Thank you. RFC Editor On Sat, Mar 20, 2010 at 08:54:25PM -0700, iesg-secretary wrote: > The IESG has approved the following document: > > - 'New ASN.1 Modules for PKIX ' > as an Informational RFC > > > This document is the product of the Public-Key Infrastructure (X.509) Working Group. > > The IESG contact persons are Tim Polk and Pasi Eronen. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-asn1-08.txt > > Technical Summary > > The X509 Certificate structure, and many associated formats, are > expressed using ASN.1. The current ASN.1 modules conform to the 1988 > version of ASN.1. This document updates those ASN.1 modules to conform to > the 2002 version of ASN.1. There are no bits-on-the-wire changes to any > of the formats; this is simply a change to the syntax. > > Working Group Summary > > This ID was discussed on the PKIX WG mailing list and at IETF 74. All > PKIX WG Last Call issues have been resolved. Discussion during PKIX WG > Last Call demonstrated working group consensus. This document has PKIX WG > support. > > No strong consensus was determined on the issue of which track the > document is to be published on. This is left to the AD discretion. > > Document Quality > > This document obsoletes/updates a number of RFCs from the PKIX WG. The > quality of the draft is comparable in quality to its predecessor. > > Personnel > > Stefan Santesson is the document Shepherd. Tim Polk is the responsible > Security Area AD. From wwwrun@core3.amsl.com Mon Mar 22 10:12:46 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id D6923E0768 for ; Mon, 22 Mar 2010 10:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cktHBxbt945V for ; Mon, 22 Mar 2010 10:12:46 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id BAAA7E0755 for ; Mon, 22 Mar 2010 10:12:46 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 9BF2D3A69E5; Mon, 22 Mar 2010 10:12:28 -0700 (PDT) Subject: [rt.ietf.org #25331] Resolved: Re: Document Action: 'New ASN.1 Modules for PKIX' to Informational RFC From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #25331 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Mon, 22 Mar 2010 10:12:28 -0700 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Thu Mar 25 12:27:30 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 75815E0777 for ; Thu, 25 Mar 2010 12:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4c6H58OyheM for ; Thu, 25 Mar 2010 12:27:30 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 53975E0768 for ; Thu, 25 Mar 2010 12:27:30 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 8B9B83A68B3; Thu, 25 Mar 2010 12:27:07 -0700 (PDT) Subject: [rt.ietf.org #25571] AutoReply: Re: Protocol Action: 'Camellia Cipher Suites for TLS' to Proposed Standard From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100325192438.GC20368@rfc-editor.org> References: <20100324202526.7E3933A683E@core3.amsl.com> <20100325192438.GC20368@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #25571 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 25 Mar 2010 12:27:07 -0700 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Camellia Cipher Suites for TLS' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #25571]. Please include the string: [rt.ietf.org #25571] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue2.html Please let us know if you have any questions. Thank you. RFC Editor On Wed, Mar 24, 2010 at 01:25:26PM -0700, iesg-secretary wrote: > The IESG has approved the following document: > > - 'Camellia Cipher Suites for TLS ' > as a Proposed Standard > > This document has been reviewed in the IETF but is not the product of an > IETF Working Group. > > The IESG contact person is Tim Polk. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-kato-tls-rfc4132bis-05.txt > > Technical Summary > > This document specifies a set of cipher suites for the Transport > Security Layer (TLS) protocol to support the Camellia encryption > algorithm as a block cipher. It amends the ciphersuites originally > specifed in RFC 4132 by counterparts using the newer cryptographic > hash algorithms from the SHA-2 familiy. This document obsoletes RFC > 4132. > > Working Group Summary > > This document was not the product of any working group. IETF > Last Call was uneventful. > > Document Quality > > There are no known implementations of the protocol. > Regional implementation is likely, reflecting current > adoption patterns for the Camellia algorithm. > > Personnel > > Tim Polk is the responsible Area Director. The authors are acting > as their own the Document Shepherd. From wwwrun@core3.amsl.com Thu Mar 25 12:27:45 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 702D4E0777 for ; Thu, 25 Mar 2010 12:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUM7ZA2p-+cp for ; Thu, 25 Mar 2010 12:27:45 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 564FDE0768 for ; Thu, 25 Mar 2010 12:27:45 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 956983A6BFD; Thu, 25 Mar 2010 12:27:22 -0700 (PDT) Subject: [rt.ietf.org #25572] AutoReply: Re: Protocol Action: 'Cryptographic Algorithms for TCP's Authentication Option, TCP-AO' to Proposed Standard From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100325192500.GD20368@rfc-editor.org> References: <20100324202820.35BD73A6D1B@core3.amsl.com> <20100325192500.GD20368@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #25572 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 25 Mar 2010 12:27:22 -0700 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Cryptographic Algorithms for TCP's Authentication Option, TCP-AO' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #25572]. Please include the string: [rt.ietf.org #25572] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue2.html Please let us know if you have any questions. Thank you. RFC Editor On Wed, Mar 24, 2010 at 01:28:20PM -0700, iesg-secretary wrote: > The IESG has approved the following document: > > - 'Cryptographic Algorithms for TCP's Authentication Option, TCP-AO ' > as a Proposed Standard > > > This document is the product of the TCP Maintenance and Minor Extensions Working Group. > > The IESG contact persons are Lars Eggert and Magnus Westerlund. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-ao-crypto-03.txt > > Technical Summary > > The TCP Authentication Option, TCP-AO, relies on security algorithms > to provide authentication between two end-points. There are many > such algorithms available, and two TCP-AO systems cannot interoperate > unless they are using the same algorithms. This document specifies > the algorithms and attributes that can be used in TCP-AO's current > manual keying mechanism. > > Document Quality > > Vendors have expressed support for this work and begun implementing > it and sharing feedback with TCPM. > > Personnel > > Wesley Eddy (Wesley.M.Eddy@nasa.gov) is the document shepherd. Lars > Eggert (lars.eggert@nokia.com) reviewed the document for the IESG. > > RFC Editor Note > > Deficiencies in xml2rfc cause an invalid table-of-contents to be > generated. As discussed during IETF-77, please manually recreate > the table-of-contents. From wwwrun@core3.amsl.com Thu Mar 25 12:30:31 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id AE0A6E0777 for ; Thu, 25 Mar 2010 12:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lrc7kGdIUWLq for ; Thu, 25 Mar 2010 12:30:30 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 94F61E0768 for ; Thu, 25 Mar 2010 12:30:30 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id CA8783A6E0D; Thu, 25 Mar 2010 12:30:07 -0700 (PDT) Subject: [rt.ietf.org #25573] AutoReply: Re: Protocol Action: 'Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)' to Proposed Standard From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100325192951.GE20368@rfc-editor.org> References: <20100324203130.0641F3A6C2C@core3.amsl.com> <20100325192951.GE20368@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #25573 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 25 Mar 2010 12:30:07 -0700 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #25573]. Please include the string: [rt.ietf.org #25573] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue2.html Please let us know if you have any questions. Thank you. RFC Editor On Wed, Mar 24, 2010 at 01:31:29PM -0700, iesg-secretary wrote: > The IESG has approved the following document: > > - 'Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence > Class (FEC) ' > as a Proposed Standard > > > This document is the product of the Multiprotocol Label Switching Working Group. > > The IESG contact persons are Adrian Farrel and Ross Callon. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-typed-wildcard-07.txt > > Technical Summary > > The LDP specification [RFC5036] for the Wildcard FEC element has > several deficiencies. This document corrects those deficiencies. In > addition, it specifies the Typed Wildcard FEC for the Prefix FEC > Element Type defined in RFC5036. > > The RFC5036 specification of the Wildcard FEC Element has the > following deficiencies which limit its utility: > > 1) The Wildcard FEC Element is untyped. There are situations where > it would be useful to be able to refer to all FECs of a given > type. > > 2) Use of the Wildcard FEC Element is limited to Label Withdraw and > Label Release messages only. There are situations where it would > be useful in Label Request messages. > > This document: > > - Addresses the above deficiencies by defining a Typed Wildcard > FEC Element and procedures for its use. > > - Specifies use of the LDP capability mechanism [RFC5561] at > session establishment time for informing a peer that an LDP > speaker is capable of handling the Typed Wildcast FEC. > > - Specifies the Typed Wildcard FEC Element for the Prefix FEC > Element specified by RFC5036. > > Note that this document does not change procedures specified for the > LDP Wildcard FEC Element by RFC5036. > > Working Group Summary > > Nothing to report. > > Document Quality > > There is at least one implementation that we know of, i.e. Cisco. > > Personnel > > Loa Andersson (loa@pi.nu) Document Shepherd. > Adrian Farrel (adrian.farrel@huawei.com) is the Responsible AD. From wwwrun@core3.amsl.com Thu Mar 25 12:34:47 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 29AC8E0774 for ; Thu, 25 Mar 2010 12:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2p1KOswWCW1y for ; Thu, 25 Mar 2010 12:34:47 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 11586E0768 for ; Thu, 25 Mar 2010 12:34:47 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 4F80D3A6D29; Thu, 25 Mar 2010 12:34:24 -0700 (PDT) Subject: [rt.ietf.org #25574] AutoReply: Re: Protocol Action: 'Extensions to the IODEF-Document Class for Reporting Phishing' to Proposed Standard From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100325193402.GF20368@rfc-editor.org> References: <20100324205323.87DA43A6DD7@core3.amsl.com> <20100325193402.GF20368@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #25574 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 25 Mar 2010 12:34:24 -0700 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Extensions to the IODEF-Document Class for Reporting Phishing' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #25574]. Please include the string: [rt.ietf.org #25574] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue2.html Please let us know if you have any questions. Thank you. RFC Editor On Wed, Mar 24, 2010 at 01:53:23PM -0700, iesg-secretary wrote: > The IESG has approved the following document: > > - 'Extensions to the IODEF-Document Class for Reporting Phishing ' > as a Proposed Standard > > This document has been reviewed in the IETF but is not the product of an > IETF Working Group. > > The IESG contact person is Tim Polk. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-cain-post-inch-phishingextns-07.txt > > Technical Summary > This document extends the Incident Object Description Exchange Format > (IODEF) to support the reporting of phishing, fraud, other types of > electronic crime, and widespread spam incidents. These extensions are > specified in XML and are flexible enough to support information > gleaned from activities throughout the entire electronic fraud cycle. > Both simple reporting and complete forensic reports are possible, as > is consolidated reporting of multiple phishing incidents. > > Working Group Summary > Testing and implementation of this document in the INCH WG had major > impact on the base IODEF Document as these tests were the first time > that portions of IODEF were used. > > Document Quality > The Anti-Phishing Working group, and Sparta, Inc (under US gov't > funding) have independent implementations that create and accept > the formats defined in this document. There are a handful of CSIRTs > and fraud-repository organizations who have agreed to share data > using this format. > > The XML defined in this document was validated using multiple XML > tools by more than one party. > > Personnel > > The Document Shepherd is Tony Hansen. Tim Polk is the responsible > Area Director. > > RFC Editor Note > > In Section C.2, please make the following substitution: > > s/.company.com/.example.com From wwwrun@core3.amsl.com Thu Mar 25 12:40:19 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 1409CE0774 for ; Thu, 25 Mar 2010 12:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTCFrSPgMFwA for ; Thu, 25 Mar 2010 12:40:18 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id E83CCE0768 for ; Thu, 25 Mar 2010 12:40:18 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 2E5C13A6991; Thu, 25 Mar 2010 12:39:55 -0700 (PDT) Subject: [rt.ietf.org #25575] AutoReply: Re: Protocol Action: 'Connectivity Preconditions for Session Description Protocol (SDP) Media Streams' to Proposed Standard From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100325194016.GG20368@rfc-editor.org> References: <20100324205627.806733A6949@core3.amsl.com> <20100325194016.GG20368@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #25575 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 25 Mar 2010 12:39:56 -0700 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'Connectivity Preconditions for Session Description Protocol (SDP) Media Streams' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.ietf.org #25575]. Please include the string: [rt.ietf.org #25575] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue2.html Please let us know if you have any questions. Thank you. RFC Editor On Wed, Mar 24, 2010 at 01:56:27PM -0700, iesg-secretary wrote: > The IESG has approved the following document: > > - 'Connectivity Preconditions for Session Description Protocol (SDP) > Media Streams ' > as a Proposed Standard > > > This document is the product of the Multiparty Multimedia Session Control Working Group. > > The IESG contact persons are Cullen Jennings and Robert Sparks. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-connectivity-precon-07.txt > > Technical Summary > This document defines a new connectivity precondition for the Session > Description Protocol (SDP) precondition framework. A connectivity > precondition can be used to delay session establishment or modification > until media stream connectivity has been successfully verified. > > Working Group Summary > The MMUSIC Working Group has consensus to publish this document as a > Proposed Standard. > > Document Quality > This document defines a new connectivity precondition type that is needed > in scenarios where it is important that the media stream succeeds. It > follows the guidelines provided in [RFC4032] to extend the SIP > preconditions framework. > > > Personnel > The Document Shepherd is Jean-Francois Mule, and the Responsible Area > Director is Cullen Jennings. From wwwrun@core3.amsl.com Thu Mar 25 12:40:40 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 284ACE0774 for ; Thu, 25 Mar 2010 12:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9Nw2IKgmGei for ; Thu, 25 Mar 2010 12:40:40 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 0EDBFE0768 for ; Thu, 25 Mar 2010 12:40:40 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 406913A6B3C; Thu, 25 Mar 2010 12:40:17 -0700 (PDT) Subject: [rt.ietf.org #25571] Resolved: Re: Protocol Action: 'Camellia Cipher Suites for TLS' to Proposed Standard From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #25571 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 25 Mar 2010 12:40:17 -0700 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Thu Mar 25 12:45:45 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 69AAFE0774 for ; Thu, 25 Mar 2010 12:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TeZikyexMSXE for ; Thu, 25 Mar 2010 12:45:45 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 4B0DEE0768 for ; Thu, 25 Mar 2010 12:45:45 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 73C823A6928; Thu, 25 Mar 2010 12:45:22 -0700 (PDT) Subject: [rt.ietf.org #25573] Resolved: Re: Protocol Action: 'Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)' to Proposed Standard From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #25573 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 25 Mar 2010 12:45:22 -0700 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Thu Mar 25 12:46:26 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 3D2AAE0774 for ; Thu, 25 Mar 2010 12:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbIzHAH-OPDY for ; Thu, 25 Mar 2010 12:46:26 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 28E13E0768 for ; Thu, 25 Mar 2010 12:46:26 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 620633A6A7A; Thu, 25 Mar 2010 12:46:03 -0700 (PDT) Subject: [rt.ietf.org #25572] Resolved: Re: Protocol Action: 'Cryptographic Algorithms for TCP's Authentication Option, TCP-AO' to Proposed Standard From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #25572 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 25 Mar 2010 12:46:03 -0700 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Thu Mar 25 12:47:02 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id D67BEE0774 for ; Thu, 25 Mar 2010 12:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QST2IrfXG4mM for ; Thu, 25 Mar 2010 12:47:01 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id C1D49E0768 for ; Thu, 25 Mar 2010 12:47:01 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 0536C3A6C20; Thu, 25 Mar 2010 12:46:38 -0700 (PDT) Subject: [rt.ietf.org #25574] Resolved: Re: Protocol Action: 'Extensions to the IODEF-Document Class for Reporting Phishing' to Proposed Standard From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #25574 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 25 Mar 2010 12:46:38 -0700 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Thu Mar 25 12:47:31 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id A80E2E0774 for ; Thu, 25 Mar 2010 12:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id km2oQJiQPYnM for ; Thu, 25 Mar 2010 12:47:31 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 922F1E0768 for ; Thu, 25 Mar 2010 12:47:31 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id CA85A3A6CEA; Thu, 25 Mar 2010 12:47:08 -0700 (PDT) Subject: [rt.ietf.org #25575] Resolved: Re: Protocol Action: 'Connectivity Preconditions for Session Description Protocol (SDP) Media Streams' to Proposed Standard From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #25575 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 25 Mar 2010 12:47:08 -0700 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Thu Mar 25 15:32:03 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id CE89AE0775 for ; Thu, 25 Mar 2010 15:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAv3q4FKzTl6 for ; Thu, 25 Mar 2010 15:32:03 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id AA6C8E076B for ; Thu, 25 Mar 2010 15:32:03 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 691433A6D5A; Thu, 25 Mar 2010 15:31:40 -0700 (PDT) Subject: [rt.ietf.org #24383] Resolved: Re: About some IAB RFCs From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.ietf.org RT-Ticket: rt.ietf.org #24383 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 25 Mar 2010 15:31:40 -0700 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Fri Apr 16 15:51:56 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 8C6B0E07CA for ; Fri, 16 Apr 2010 15:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCO2P-SyYumu for ; Fri, 16 Apr 2010 15:51:56 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 68C95E07AE for ; Fri, 16 Apr 2010 15:51:56 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 14EDD28C0FF; Fri, 16 Apr 2010 15:52:02 -0700 (PDT) Subject: [www.ietf.org/rt #26302] AutoReply: Re: Document Action: 'Location Hiding: Problem Statement and Requirements' to Informational RFC From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100416225153.GB15844@rfc-editor.org> References: <20100416150926.CB0623A6B53@core3.amsl.com> <20100416225153.GB15844@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: www.ietf.org/rt RT-Ticket: www.ietf.org/rt #26302 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 16 Apr 2010 15:52:03 -0700 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'Location Hiding: Problem Statement and Requirements' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [www.ietf.org/rt #26302]. Please include the string: [www.ietf.org/rt #26302] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue2.html Please let us know if you have any questions. Thank you. RFC Editor On Fri, Apr 16, 2010 at 08:09:26AM -0700, iesg-secretary wrote: > The IESG has approved the following document: > > - 'Location Hiding: Problem Statement and Requirements ' > as an Informational RFC > > > This document is the product of the Emergency Context Resolution with Internet Technologies Working Group. > > The IESG contact persons are Robert Sparks and Gonzalo Camarillo. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-location-hiding-req-04.txt > > Technical Summary > > The emergency services architecture developed in the IETF Emergency > Context Resolution with Internet Technology (ECRIT) working group > describes an architecture where location information is provided by > access networks to end points or VoIP service providers in order to > determine the correct dial string and information to route the call > to a Public Safety Answering Point (PSAP). For determining the PSAP > Uniform Resource Identifier (URI) the usage of the Location-to- > Service Translation (LoST) Protocol is envisioned. > > This document provides a problem statement and lists requirements > for situations where the Internet Access Provider (IAP) and/or the > Internet Service Provider (ISP) are only willing to disclose > limited or no location information. > > Working Group Summary > > There is consensus in the WG to publish this document. > > Document Quality > > The document has been reviewed by ECRIT working group members > and feedback was provided by participants from various > emergency services workshops. > > Personnel > > Marc Linsner is the document shepherd for this document. From wwwrun@core3.amsl.com Mon Apr 19 07:37:05 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 75535130007 for ; Mon, 19 Apr 2010 07:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGlo+P8GzYjJ for ; Mon, 19 Apr 2010 07:37:05 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 59C3D130005 for ; Mon, 19 Apr 2010 07:37:05 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 479273A6AF5; Mon, 19 Apr 2010 07:37:12 -0700 (PDT) Subject: [www.ietf.org/rt #26302] Resolved: Re: Document Action: 'Location Hiding: Problem Statement and Requirements' to Informational RFC From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: www.ietf.org/rt RT-Ticket: www.ietf.org/rt #26302 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Mon, 19 Apr 2010 07:37:13 -0700 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Thu Jun 10 09:52:50 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-202.4 required=5.0 tests=AWL,BAYES_00, SUBJECT_FUZZY_TION,SUBJECT_IN_WHITELIST,USER_IN_WHITELIST autolearn=no version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 288FDE068B; Thu, 10 Jun 2010 09:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6llYhn122PHx; Thu, 10 Jun 2010 09:52:49 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 7142DE0656; Thu, 10 Jun 2010 09:52:49 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id B86C53A69AA; Thu, 10 Jun 2010 09:52:46 -0700 (PDT) From: IESG Secretary To: rfc-editor@rfc-editor.org, rfc-ise@rfc-editor.org Cc: iana@iana.org, iesg@ietf.org, ietf-announce@ietf.org Subject: CORRECTTION Re: Informational RFC to be: draft-meadors-ediint-features-header-07.txt Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100610165246.B86C53A69AA@core3.amsl.com> Date: Thu, 10 Jun 2010 09:52:46 -0700 (PDT) The IESG has no problem with the publication of 'EDI-INT Features Header' as an Informational RFC. The IESG would also like the IRSG or RFC-Editor to review the comments in the datatracker (https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13595&rfc_flag=0) related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the comment log. The IESG contact person is Alexey Melnikov. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-meadors-ediint-features-header-07.txt The process for such documents is described at http://www.rfc-editor.org/indsubs.html. Thank you, The IESG Secretary Technical Summary EDI-INT applications provide for a secure means of payload document transport. The original intent was for transport of a single EDI or XML document. However, as AS1 [RFC3335], AS2 [RFC4130] and AS3 [RFC4823] matured, other features and application logic were implemented upon EDI-INT standards. Since these features go beyond but do not violate the basic premise of EDI-INT, a means is needed to communicate to trading partners features which are supported by the originating user agent. The EDIINT Features header indicates the capability of the user agent to support the listed feature with its trading partner without out- of-band communication and agreement. Working Group Summary This document is not the result of any IETF Working Group, it is an independent submission to the RFC Editor. Document Quality Alexey Melnikov has reviewed this specification for conflict with IETF work and for comflict with IETF processes as specified in RFC 5742. Personnel Alexey Melnikov is the Responsible Area Director. RFC Editor Note The IESG believes that this work doesn't conflict with any work done in IETF, so it has no note to insert into this document, and no objection to its publication. Note that the document is currently waiting for new email/web header field approval from the designated IANA expert. From wwwrun@core3.amsl.com Fri Jun 25 19:09:11 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 4EB50E068E for ; Fri, 25 Jun 2010 19:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIhCBa9oY-EN for ; Fri, 25 Jun 2010 19:09:10 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 9E14AE0673 for ; Fri, 25 Jun 2010 19:09:10 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 32F583A687C; Fri, 25 Jun 2010 19:09:00 -0700 (PDT) Subject: [www.ietf.org/rt #28193] AutoReply: Re: Document Action: 'ZRTP: Media Path Key Agreement for Unicast Secure RTP' to Informational RFC From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100626020908.GC5742@rfc-editor.org> References: <20100625221142.2A3E23A68D8@core3.amsl.com> <20100626020908.GC5742@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: www.ietf.org/rt RT-Ticket: www.ietf.org/rt #28193 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 25 Jun 2010 19:09:01 -0700 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'ZRTP: Media Path Key Agreement for Unicast Secure RTP' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [www.ietf.org/rt #28193]. Please include the string: [www.ietf.org/rt #28193] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue2.html Please let us know if you have any questions. Thank you. RFC Editor On Fri, Jun 25, 2010 at 03:11:42PM -0700, iesg-secretary wrote: > The IESG has approved the following document: > > - 'ZRTP: Media Path Key Agreement for Unicast Secure RTP ' > as an Informational RFC > > This document has been reviewed in the IETF but is not the product of an > IETF Working Group. > > The IESG contact person is Robert Sparks. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-zimmermann-avt-zrtp-22.txt > > Technical Summary > > This document defines ZRTP, a protocol for media path Diffie-Hellman > exchange to agree on a session key and parameters for establishing > Secure Real-time Transport Protocol (SRTP) sessions for VoIP > applications. The ZRTP protocol is media path keying because it is > multiplexed on the same port as RTP and does not require support in > the signaling protocol. ZRTP does not assume a Public Key > Infrastructure (PKI) or require the complexity of certificates in end > devices. For the media session, ZRTP provides confidentiality, > protection against man-in-the-middle (MiTM) attacks, and, in cases > where the signaling protocol provides end-to-end integrity > protection, authentication. ZRTP can utilize a Session Description > Protocol (SDP) attribute to provide discovery and authentication > through the signaling channel. To provide best effort SRTP, ZRTP > utilizes normal RTP/AVP profiles. ZRTP secures media sessions which > include a voice media stream, and can also secure media sessions > which do not include voice by using an optional digital signature. > > IETF Discussion Summary > > This protocol was proposed as a solution for keying SRTP and received > > > significant review and discussion while it was being considered. The > IETF chose a different proposal (draft-ietf-avt-dtls-srtp) to publish > as Proposed Standard. > > Document Quality > > There are multiple implementations of this protocol. > A reference implementation of ZRTP is available as Zfone. From wwwrun@core3.amsl.com Mon Jun 28 09:20:27 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 17F14E069E for ; Mon, 28 Jun 2010 09:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TImJRy7Jxis0 for ; Mon, 28 Jun 2010 09:20:26 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 6BA6EE069A for ; Mon, 28 Jun 2010 09:20:26 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id C6A7C3A6915; Mon, 28 Jun 2010 09:20:15 -0700 (PDT) Subject: [www.ietf.org/rt #28193] Resolved: Re: Document Action: 'ZRTP: Media Path Key Agreement for Unicast Secure RTP' to Informational RFC From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: www.ietf.org/rt RT-Ticket: www.ietf.org/rt #28193 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Mon, 28 Jun 2010 09:20:15 -0700 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Tue Jun 29 08:05:27 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 4E13EE0685 for ; Tue, 29 Jun 2010 08:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3Jdhqc8zdFa for ; Tue, 29 Jun 2010 08:05:05 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id C40E3E0652 for ; Tue, 29 Jun 2010 08:05:04 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id C0CDF3A681F; Tue, 29 Jun 2010 08:04:53 -0700 (PDT) Subject: [www.ietf.org/rt #28306] AutoReply: Re: Document Action: 'Session Initiation Protocol (SIP) User Agent Configuration' to Informational RFC From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100629150501.GA5877@rfc-editor.org> References: <20100628195839.7FB763A69C6@core3.amsl.com> <20100629150501.GA5877@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: www.ietf.org/rt RT-Ticket: www.ietf.org/rt #28306 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 29 Jun 2010 08:04:53 -0700 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Document Action: 'Session Initiation Protocol (SIP) User Agent Configuration' to Informational RFC", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [www.ietf.org/rt #28306]. Please include the string: [www.ietf.org/rt #28306] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue2.html Please let us know if you have any questions. Thank you. RFC Editor On Mon, Jun 28, 2010 at 12:58:39PM -0700, iesg-secretary wrote: > The IESG has approved the following document: > > - 'Session Initiation Protocol (SIP) User Agent Configuration ' > as an Informational RFC > > This document has been reviewed in the IETF but is not the product of an > IETF Working Group. > > The IESG contact person is Gonzalo Camarillo. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-lawrence-sipforum-user-agent-config-03.txt > > Technical Summary > > This document defines procedures for how a SIP User Agent should > locate, retrieve, and maintain current configuration information from > a Configuration Service. > > Working Group Summary > > The work was largely done at the SIP Forum. > > Document Quality > > Although this document was not started at the IETF, it has > received review by many IETF participants that work in the > relevant space. > > Personnel > > Gonzalo Camarillo is the responsible AD. From wwwrun@core3.amsl.com Tue Jun 29 08:09:25 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 8670BE0685 for ; Tue, 29 Jun 2010 08:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C15CMHhSX13r for ; Tue, 29 Jun 2010 08:09:24 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id AC5ECE0652 for ; Tue, 29 Jun 2010 08:09:24 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id AA2A23A6B96; Tue, 29 Jun 2010 08:09:13 -0700 (PDT) Subject: [www.ietf.org/rt #28307] AutoReply: Re: Protocol Action: 'A Dedicated Routing Policy Specification Language Interface Identifier for Operational Testing' to Proposed Standard From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100629150922.GB5877@rfc-editor.org> References: <20100628163359.815E43A6A68@core3.amsl.com> <20100629150922.GB5877@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: www.ietf.org/rt RT-Ticket: www.ietf.org/rt #28307 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 29 Jun 2010 08:09:13 -0700 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'A Dedicated Routing Policy Specification Language Interface Identifier for Operational Testing' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [www.ietf.org/rt #28307]. Please include the string: [www.ietf.org/rt #28307] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue2.html Please let us know if you have any questions. Thank you. RFC Production Center On Mon, Jun 28, 2010 at 09:33:59AM -0700, iesg-secretary wrote: > The IESG has approved the following document: > > - 'A Dedicated Routing Policy Specification Language Interface Identifier > for Operational Testing ' > as a Proposed Standard > > This document has been reviewed in the IETF but is not the product of an > IETF Working Group. > > The IESG contact person is Ron Bonica. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-haberman-rpsl-reachable-test-04.txt > > Technical Summary > > The deployment of new IP connectivity typically results in intermittent > reachability for numerous reasons which are outside the scope of this > document. In order to aid in the debugging of these persistent problems, > this document proposes the creation of a new Routing Policy Specification > Language attribute that allows a network to advertise an IP address which > is reachable and can be used as a target for diagnostic tests (e.g., > pings). > > > Working Group Summary > > This document was not produced by a WG > > Document Quality > > This is a fairly simple draft. It has been reviewed by individuals who > understand RPSL. > > Personnel > > Ron Bonica is the sponsoring AD From wwwrun@core3.amsl.com Tue Jun 29 08:15:06 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 252DFE0685 for ; Tue, 29 Jun 2010 08:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id img5bDPh7onD for ; Tue, 29 Jun 2010 08:15:02 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id B7683E0652 for ; Tue, 29 Jun 2010 08:15:01 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id DE3EF3A6845; Tue, 29 Jun 2010 08:14:49 -0700 (PDT) Subject: [www.ietf.org/rt #28308] AutoReply: Re: Protocol Action: 'An Extension for EAP-Only Authentication in IKEv2' to Proposed Standard From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100629151442.GC5877@rfc-editor.org> References: <20100628164354.2E9F93A6A81@core3.amsl.com> <20100629151442.GC5877@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: www.ietf.org/rt RT-Ticket: www.ietf.org/rt #28308 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 29 Jun 2010 08:14:49 -0700 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: Protocol Action: 'An Extension for EAP-Only Authentication in IKEv2' to Proposed Standard", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [www.ietf.org/rt #28308]. Please include the string: [www.ietf.org/rt #28308] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Greetings, We have added this document to our online queue at: http://www.rfc-editor.org/queue2.html Please let us know if you have any questions. Thank you. RFC Production Center On Mon, Jun 28, 2010 at 09:43:54AM -0700, iesg-secretary wrote: > The IESG has approved the following document: > > - 'An Extension for EAP-Only Authentication in IKEv2 ' > as a Proposed Standard > > > This document is the product of the IP Security Maintenance and Extensions Working Group. > > The IESG contact persons are Sean Turner and Tim Polk. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-eap-mutual-05.txt > > Technical Summary > > This document specifies how EAP methods that provide mutual > authentication and key agreement can be used to provide > extensible responder authentication for > IKEv2 based on methods other than public key signatures. > > Working Group Summary > > Nothing particular to note about WG discussions. It did > receive an adequate amount of review. > > Document Quality > > One developer said they had implemented this experimentally > and hand no problem. There are other developers who have > expressed interest in implementing it in the future. > > Personnel > > Paul Hoffman (paul.hoffman@vpnc.org) is the Document Shepherd. > Sean Turner (turners@ieca.com) is the Responsible Area Director. > The IANA Expert for the registries in this document is > Tero Kivinen (kivinen@iki.fi). From wwwrun@core3.amsl.com Tue Jun 29 08:24:07 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id DB457E0689 for ; Tue, 29 Jun 2010 08:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7lBiRwgFj4j for ; Tue, 29 Jun 2010 08:24:07 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 4756CE0685 for ; Tue, 29 Jun 2010 08:24:07 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 4087E3A6BEC; Tue, 29 Jun 2010 08:23:55 -0700 (PDT) Subject: [www.ietf.org/rt #28306] Resolved: Re: Document Action: 'Session Initiation Protocol (SIP) User Agent Configuration' to Informational RFC From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: www.ietf.org/rt RT-Ticket: www.ietf.org/rt #28306 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 29 Jun 2010 08:23:56 -0700 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Tue Jun 29 08:41:29 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 8731EE0689 for ; Tue, 29 Jun 2010 08:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26wPU5pHPe3Y for ; Tue, 29 Jun 2010 08:41:28 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id DD02FE0685 for ; Tue, 29 Jun 2010 08:41:28 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id D512D3A6827; Tue, 29 Jun 2010 08:41:17 -0700 (PDT) Subject: [www.ietf.org/rt #28307] Resolved: Re: Protocol Action: 'A Dedicated Routing Policy Specification Language Interface Identifier for Operational Testing' to Proposed Standard From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: www.ietf.org/rt RT-Ticket: www.ietf.org/rt #28307 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 29 Jun 2010 08:41:17 -0700 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Tue Jun 29 08:43:07 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id AB74FE068E for ; Tue, 29 Jun 2010 08:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQNHIvtvngPh for ; Tue, 29 Jun 2010 08:43:07 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 8C61FE0685 for ; Tue, 29 Jun 2010 08:43:07 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 83B4F3A6A5E; Tue, 29 Jun 2010 08:42:56 -0700 (PDT) Subject: [www.ietf.org/rt #28308] Resolved: Re: Protocol Action: 'An Extension for EAP-Only Authentication in IKEv2' to Proposed Standard From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: www.ietf.org/rt RT-Ticket: www.ietf.org/rt #28308 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Tue, 29 Jun 2010 08:42:56 -0700 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Thu Jul 15 09:29:52 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-202.5 required=5.0 tests=AWL,BAYES_00, SUBJECT_IN_WHITELIST,USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 5D895E0647 for ; Thu, 15 Jul 2010 09:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdWVZ65U1sQV for ; Thu, 15 Jul 2010 09:29:47 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 1B2D4E062D for ; Thu, 15 Jul 2010 09:29:47 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id E0BEE3A69C6; Thu, 15 Jul 2010 09:29:35 -0700 (PDT) Subject: [www.ietf.org/rt #28887] AutoReply: Re: draft-rosen-vpn-mcast From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100715162923.GA32592@rfc-editor.org> References: <20100715162923.GA32592@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: www.ietf.org/rt RT-Ticket: www.ietf.org/rt #28887 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 15 Jul 2010 09:29:35 -0700 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Re: draft-rosen-vpn-mcast", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [www.ietf.org/rt #28887]. Please include the string: [www.ietf.org/rt #28887] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Hi Adrian, I'm not sure when the state was changed, but it looks correct now, as https://datatracker.ietf.org/doc/draft-rosen-vpn-mcast/ shows: RFC Ed Queue RFC Editor State: EDIT If this is not the page you were looking at, please let us know. FYI: we received the "no problem with" message from the Secretariat 21 June. Thanks for bringing this to our attention and making sure we'll all in sync! Thanks! Sandy On Thu, Jul 15, 2010 at 11:41:46AM +0100, Adrian Farrel wrote: > Hi, > > I note that this independent submission is stuck in "Approved-announcement > sent". > > Is there further action required? > > Cheers, > Adrian From wwwrun@core3.amsl.com Thu Jul 15 14:32:52 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-202.5 required=5.0 tests=AWL,BAYES_00, SUBJECT_IN_WHITELIST,USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 6F9E8E066D for ; Thu, 15 Jul 2010 14:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iC3WFPY1OQW1 for ; Thu, 15 Jul 2010 14:32:51 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id BB26DE0644 for ; Thu, 15 Jul 2010 14:32:51 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 3DE543A69DE; Thu, 15 Jul 2010 14:32:39 -0700 (PDT) Subject: [www.ietf.org/rt #28887] Re: draft-rosen-vpn-mcast From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20100715162923.GA32592@rfc-editor.org> References: <20100715162923.GA32592@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: www.ietf.org/rt RT-Ticket: www.ietf.org/rt #28887 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 15 Jul 2010 14:32:40 -0700 Hi Sandy, This was on our end. The state in the tracker just hadn't been updated properly for this draft. Best regards, Cindy On Thu Jul 15 09:29:35 2010, rfc-editor@rfc-editor.org wrote: > Hi Adrian, > > I'm not sure when the state was changed, but it looks correct now, as > https://datatracker.ietf.org/doc/draft-rosen-vpn-mcast/ shows: > > RFC Ed Queue > RFC Editor State: EDIT > > If this is not the page you were looking at, please let us know. > > FYI: we received the "no problem with" message from the Secretariat > 21 June. > > Thanks for bringing this to our attention and making sure we'll all in > sync! > > Thanks! > Sandy > > > > On Thu, Jul 15, 2010 at 11:41:46AM +0100, Adrian Farrel wrote: > > Hi, > > > > I note that this independent submission is stuck in "Approved- > announcement > > sent". > > > > Is there further action required? > > > > Cheers, > > Adrian > From wwwrun@core3.amsl.com Thu Jul 15 14:32:56 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-202.5 required=5.0 tests=AWL,BAYES_00, SUBJECT_IN_WHITELIST,USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 18F8CE066D for ; Thu, 15 Jul 2010 14:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f66-eqUIXuke for ; Thu, 15 Jul 2010 14:32:55 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id B952EE0644 for ; Thu, 15 Jul 2010 14:32:55 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 578243A6840; Thu, 15 Jul 2010 14:32:43 -0700 (PDT) Subject: [www.ietf.org/rt #28887] Resolved: Re: draft-rosen-vpn-mcast From: "Cindy Morgan via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: www.ietf.org/rt RT-Ticket: www.ietf.org/rt #28887 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: cmorgan@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 15 Jul 2010 14:32:44 -0700 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Fri Jul 30 01:30:31 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-202.5 required=5.0 tests=AWL,BAYES_00, SUBJECT_IN_WHITELIST,USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 5325CE06C4; Fri, 30 Jul 2010 01:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxissXFN90zr; Fri, 30 Jul 2010 01:30:30 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 639AAE060E; Fri, 30 Jul 2010 01:30:30 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 3EEA13A6AB8; Fri, 30 Jul 2010 01:30:04 -0700 (PDT) From: IESG Secretary To: rfc-editor@rfc-editor.org, rfc-ise@rfc-editor.org Cc: iesg@ietf.org, iana@iana.org, ietf-announce@ietf.org Subject: Re: Informational RFC to be: draft-keromytis-tls-authz-keynote-07.txt Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100730083005.3EEA13A6AB8@core3.amsl.com> Date: Fri, 30 Jul 2010 01:30:05 -0700 (PDT) The IESG has no problem with the publication of 'Transport Layer Security (TLS) Authorization Using KeyNote' as an Informational RFC. The IESG would also like the RFC-Editor to review the comments in the datatracker (https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17180&rfc_flag=0) related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the comment log. The IESG contact person is Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-keromytis-tls-authz-keynote-07.txt The process for such documents is described at http://www.rfc-editor.org/indsubs.html. Thank you, The IESG Secretary Technical Summary This document specifies the use of the KeyNote trust-management system as an authorization extension in the Transport Layer Security (TLS) Handshake Protocol, according to [AUTHZ]. Extensions carried in the client and server hello messages confirm that both parties support the desired authorization data types. Then, if supported by both the client and the server, KeyNote credentials are exchanged during the supplemental data handshake message. Working Group Summary This document is an independent submission. Document Quality While there is no existing implementations of the protocol, implementation should be straightforward with appropriate TLS toolkits. Future versions of the keynote distribution are expected to include any necessary functionality to encode and decode the required data structures. Personnel Tim Polk reviewed this document for the IESG. RFC Editor Note Proposed response to the RFC Editor 1. The IESG has concluded that there is no conflict between this document and IETF work. From wwwrun@core3.amsl.com Mon Aug 23 09:58:39 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-202.5 required=5.0 tests=AWL,BAYES_00, SUBJECT_IN_WHITELIST,USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 20267E06CE; Mon, 23 Aug 2010 09:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXaC331e4UpA; Mon, 23 Aug 2010 09:58:38 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 229A9E0610; Mon, 23 Aug 2010 09:58:38 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 34D773A689C; Mon, 23 Aug 2010 09:58:03 -0700 (PDT) From: IESG Secretary To: rfc-editor@rfc-editor.org, rfc-ise@rfc-editor.org Cc: iesg@ietf.org, iana@iana.org, ietf-announce@ietf.org Subject: Re: Experimental RFC to be: Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100823165804.34D773A689C@core3.amsl.com> Date: Mon, 23 Aug 2010 09:58:04 -0700 (PDT) The IESG has no problem with the publication of 'A Childless Initiation of the IKE SA' as an Experimental RFC. The IESG would also like the RFC-Editor to review the comments in the datatracker (https://datatracker.ietf.org/doc/draft-nir-ipsecme-childless/) related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the comment log. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-nir-ipsecme-childless/ The process for such documents is described at http://www.rfc-editor.org/indsubs.html Thank you, The IESG Secretary Technical Summary This document describes an extension to the IKEv2 protocol that allows an IKE SA to be created and authenticated without generating a Child SA. Working Group Summary This document is not the product of a WG. Document Quality This is an RFC-editor independent submission. Personnel The responsible Area Director is Sean Turner. RFC Editor Note The IESG has concluded that this work is related to IETF work done in IPSECME WG, but this relationship does not prevent publishing. From wwwrun@core3.amsl.com Thu Nov 4 14:01:38 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-202.5 required=5.0 tests=AWL,BAYES_00, SUBJECT_IN_WHITELIST,USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 3ABBFE06B1 for ; Thu, 4 Nov 2010 14:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yqEjMFzrTUS for ; Thu, 4 Nov 2010 14:01:37 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id A3BE4E0656 for ; Thu, 4 Nov 2010 14:01:37 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 7094628C100; Thu, 4 Nov 2010 14:01:26 -0700 (PDT) Subject: [www.ietf.org/rt #32421] AutoReply: draft-ietf-v6ops-ra-guard-08.txt From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20101104210133.GC23188@rfc-editor.org> References: <20101104210133.GC23188@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: www.ietf.org/rt RT-Ticket: www.ietf.org/rt #32421 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 04 Nov 2010 14:01:26 -0700 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "draft-ietf-v6ops-ra-guard-08.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [www.ietf.org/rt #32421]. Please include the string: [www.ietf.org/rt #32421] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Hi! We note that draft-ietf-v6ops-ra-guard-08.txt has been approved for publication as an Informational RFC (according to the message here: https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=934&k2=8541&tid=1288901228). Howver, we are unable to find a message request from the Secretariat. Could you plese resend? Thanks! Sandy From wwwrun@core3.amsl.com Thu Nov 4 14:16:29 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-202.5 required=5.0 tests=AWL,BAYES_00, SUBJECT_IN_WHITELIST,USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id AE7BDE06B1 for ; Thu, 4 Nov 2010 14:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2lLjjIIKFGS for ; Thu, 4 Nov 2010 14:16:29 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 3C1B3E0656 for ; Thu, 4 Nov 2010 14:16:29 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 11BF328C0E6; Thu, 4 Nov 2010 14:16:17 -0700 (PDT) Subject: [www.ietf.org/rt #32422] AutoReply: draft-ietf-v6ops-rogue-ra-02.txt From: "IETF-IESG via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20101104211625.GD23188@rfc-editor.org> References: <20101104211625.GD23188@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: www.ietf.org/rt RT-Ticket: www.ietf.org/rt #32422 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: rfc-editor@rfc-editor.org To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 04 Nov 2010 14:16:18 -0700 Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "draft-ietf-v6ops-rogue-ra-02.txt", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [www.ietf.org/rt #32422]. Please include the string: [www.ietf.org/rt #32422] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary@ietf.org ------------------------------------------------------------------------- Hi! We note that draft-ietf-v6ops-rogue-ra-02.txt has been approved for publication as an Informational RFC (according to the message here: https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=934&k2=8555&tid=1288901228. Howver, we are unable to find a message request from the Secretariat. Could you plese resend? Thanks! Sandy From wwwrun@core3.amsl.com Fri Nov 5 00:53:38 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-202.5 required=5.0 tests=AWL,BAYES_00, SUBJECT_IN_WHITELIST,USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 254B6E06F2 for ; Fri, 5 Nov 2010 00:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCfppQKe8+p6 for ; Fri, 5 Nov 2010 00:53:37 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 3B3CEE06E9 for ; Fri, 5 Nov 2010 00:53:37 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id C2B743A68E5; Fri, 5 Nov 2010 00:53:24 -0700 (PDT) Subject: [www.ietf.org/rt #32421] draft-ietf-v6ops-ra-guard-08.txt From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: <20101104210133.GC23188@rfc-editor.org> References: <20101104210133.GC23188@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: www.ietf.org/rt RT-Ticket: www.ietf.org/rt #32421 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 05 Nov 2010 00:53:24 -0700 Hi Sandy, In regards to the issue of the announcements, we have forwarded four announcements (three Document Actions, and one Protocol Action) that have been sent since October 27, 2010. There is also an independent "no problem" message sent for draft-katagi-clefia, can you confirm whether or not the RFC Editor received this message? Thank you! Amy On Thu Nov 04 14:01:26 2010, rfc-editor@rfc-editor.org wrote: > Hi! > > We note that draft-ietf-v6ops-ra-guard-08.txt has been approved for > publication as an Informational RFC (according to the message here: > https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=934&k2=8541&tid=1288901228). > > Howver, we are unable to find a message request from the Secretariat. > Could you plese resend? > > Thanks! > Sandy > From wwwrun@core3.amsl.com Fri Nov 5 11:13:02 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-202.5 required=5.0 tests=AWL,BAYES_00, SUBJECT_IN_WHITELIST,USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 90B8EE06B1 for ; Fri, 5 Nov 2010 11:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uomBHE5nwIY for ; Fri, 5 Nov 2010 11:13:01 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id D058FE060F for ; Fri, 5 Nov 2010 11:13:01 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 269DC3A691B; Fri, 5 Nov 2010 11:12:48 -0700 (PDT) Subject: Re: [www.ietf.org/rt #32421] draft-ietf-v6ops-ra-guard-08.txt From: "Lynne Bartholomew via RT" Reply-To: iesg-secretary@ietf.org In-Reply-To: References: <20101104210133.GC23188@rfc-editor.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: www.ietf.org/rt RT-Ticket: www.ietf.org/rt #32421 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: lbartholomew@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Fri, 05 Nov 2010 11:12:48 -0700 Hi, Amy. Looks like the RFC Editor did not receive the message re. Independent Submission draft-katagi-clefia. Could you please forward it? Thanks! Lynne On Nov 5, 2010, at 12:53 AM, Amy Vezza via RT wrote: > Hi Sandy, > > In regards to the issue of the announcements, we have forwarded four > announcements (three Document Actions, and one Protocol Action) that > have been sent since October 27, 2010. There is also an independent "no > problem" message sent for draft-katagi-clefia, can you confirm whether > or not the RFC Editor received this message? > > Thank you! > > Amy > > > > On Thu Nov 04 14:01:26 2010, rfc-editor@rfc-editor.org wrote: >> Hi! >> >> We note that draft-ietf-v6ops-ra-guard-08.txt has been approved for >> publication as an Informational RFC (according to the message here: >> > https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=934&k2=8541&tid=1288901228). >> >> Howver, we are unable to find a message request from the Secretariat. >> Could you plese resend? >> >> Thanks! >> Sandy >> > > > From wwwrun@core3.amsl.com Thu Nov 11 00:35:54 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-202.5 required=5.0 tests=AWL,BAYES_00, SUBJECT_IN_WHITELIST,USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 65F65E06EF for ; Thu, 11 Nov 2010 00:35:54 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HWDXFWgXPAm for ; Thu, 11 Nov 2010 00:35:53 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id C0314E06EE for ; Thu, 11 Nov 2010 00:35:53 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 00DE73A6935; Thu, 11 Nov 2010 00:35:23 -0800 (PST) Subject: [www.ietf.org/rt #32421] Resolved: draft-ietf-v6ops-ra-guard-08.txt From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: www.ietf.org/rt RT-Ticket: www.ietf.org/rt #32421 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 11 Nov 2010 00:35:23 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened. From wwwrun@core3.amsl.com Thu Nov 11 00:38:19 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rfcpa.amsl.com X-Spam-Level: X-Spam-Status: No, score=-202.5 required=5.0 tests=AWL,BAYES_00, SUBJECT_IN_WHITELIST,USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Original-To: rfc-editor@rfc-editor.org Delivered-To: rfc-editor@rfc-editor.org Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 5A39EE06EF for ; Thu, 11 Nov 2010 00:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.rfc-editor.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8ONNtuM+sPl for ; Thu, 11 Nov 2010 00:38:19 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by rfc-editor.org (Postfix) with ESMTP id 373E3E06EE for ; Thu, 11 Nov 2010 00:38:19 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 840723A68FD; Thu, 11 Nov 2010 00:37:49 -0800 (PST) Subject: [www.ietf.org/rt #32422] Resolved: draft-ietf-v6ops-rogue-ra-02.txt From: "Amy Vezza via RT" Reply-To: iesg-secretary@ietf.org Message-ID: Precedence: bulk X-RT-Loop-Prevention: www.ietf.org/rt RT-Ticket: www.ietf.org/rt #32422 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: avezza@amsl.com To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Thu, 11 Nov 2010 00:37:49 -0800 We believe that this resolves your issue, and this ticket has therefore been marked as closed in our system. If the issue is not resolved to your satisfaction, or if you have additional questions, please reply to this message using the above trouble ticket number, and your ticket will be automatically reopened.