From rfc-ed@ISI.EDU Tue Jun 10 14:10:47 2003 X-Sender: (Unverified) Date: Tue, 10 Jun 2003 16:57:46 -0400 To: RFC Editor From: The IESG Subject: Re: IESG Statement on draft-malis-sonet-ces-mpls-05.txt Cc: IESG X-Spam-Status: No, hits=1.6 required=5.0 tests=AWL,MSG_ID_ADDED_BY_MTA_3,SPAM_PHRASE_00_01 version=2.43 X-AntiVirus: scanned by AMaViS 0.2.1 Status: RO X-Lines: 26 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Length: 1048 To the RFC Editor: The IESG has consulted with the PWE3 WG chairs about the relationship of this document with the work of the PWE3 working group. The PWE3 WG moved beyond draft-malis-sonet-ces-mpls-05.txt as the base for one of its chartered documents, draft-ietf-pwe3-sonet-01.txt. The WG's chartered draft contains much material meeting requirements (security, congestion avoidance, IP IP support as well as MPLS) not envisioned by draft-malis-sonet-ces-mpls-05.txt, because of the WG charter and the working group interoperabilty discussions going on. Leaving aside the charter requirements, the documents have the same subject matter. Publication of draft-malis-sonet-ces-mpls-05 at this time would therefore constitute an end-run around the IETF process. The IESG therefore finds it advisable that draft-malis-sonet-ces-mpls-05.txt not be published at this time. Publication after the working group document is published, for informational purposes, if the author so desires, would not present a problem. Thank you, The IESG Secretary From rfc-ed@ISI.EDU Fri Dec 5 10:42:26 2003 Date: Fri, 5 Dec 2003 13:41:56 -0500 (EST) From: IESG Secretary X-X-Sender: amyk@ietf.org To: rfc-editor@rfc-editor.org cc: iesg@ietf.org Subject: Urgent: Request for Expedited Handling of draft-ietf-sipping-reg-event-00.txt X-AntiVirus: scanned by AMaViS 0.2.1 X-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,USER_AGENT_PINE version=2.55 Status: RO X-Lines: 12 Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Length: 374 Dear RFC Editor, The IESG requests expedited handling of draft-ietf-sipping-reg-event-00.txt, which is currently in the RFC Editor queue. Specifically, 3GPP2 needs an RFC number that they can include in one of their standards. 3GPP2 has reported that they need an RFC number in hand by December 11 in order to meet their approval deadlines. Thank you, The IESG Secretary From rfc-ed@ISI.EDU Wed Mar 3 16:21:42 2004 Date: Wed, 3 Mar 2004 19:20:50 -0500 (EST) From: IESG Secretary X-X-Sender: amyk@ietf.org To: rfc-editor@rfc-editor.org cc: iesg@ietf.org Subject: Request for Expedited Handling of draft-ietf-pkix-sonof3039-06 X-AntiVirus: scanned by AMaViS 0.2.1 X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Status: RO X-Lines: 24 Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Length: 698 Dear RFC Editor: The IESG requests expedited handling of draft-ietf-pkix-sonof3039-06, which has been approved and announced by the IESG. The justification for expedited handling is as follows: Two ETSI standards were circulated for voting: TS 102 280: X.509 V.3 Certificate Profile for Certificates Issued to Natural Persons and TS 101 862bis: Qualified certificate profile The drafts that were circulated reference RFC 3039. Since the IESG has just approved a document that will obsolete RFC 3039, it is highly desirable for these ETSI standards to reference the new document. For this to happen, we need to provide an RFC number to ETSI by March 20, 2004. Thank you. The IESG Secretary From rfc-ed@ISI.EDU Tue Jun 15 15:13:51 2004 Date: Tue, 15 Jun 2004 18:11:21 -0400 (EDT) From: IESG Secretary X-X-Sender: amyk@ietf.org To: rfc-editor@rfc-editor.org cc: iesg-secretary@ietf.org Subject: Expedited Handling Request for draft-singer-avt-3gpp-mime X-ISI-4-30-3-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Status: RO X-Lines: 12 Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Length: 306 Dear RFC Editor, The IESG requests expedited publication of draft-singer-avt-3gpp-mime-01.txt, which is currently in the RFC Editor queue. Specifically, 3GPP needs an RFC number by August 16, 2004, so that they can reference the document in one in one of their standards. Thank you, The IESG Secretary From rfc-ed@ISI.EDU Fri Sep 9 11:00:59 2005 To: RFC Editor Cc: ietf-announce@ietf.org, iab@iab.org From: IESG Secretary Date: Fri, 09 Sep 2005 13:59:11 -0400 X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Subject: Obsoleting RFC 1818 and RFC 1871 X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Status: RO X-Lines: 7 Content-Type: text/plain Content-Length: 287 In its meeting of September 1, 2005, the IESG noted that the contents of RFC 1818 and RFC 1871 were superseded by sections 5 and 9 of RFC 2026 respectively. RFC 1818 (BCP 1) and RFC 1871 (BCP 2) are therefore deemed to be obsoleted by RFC 2026 (BCP 9) and are reclassified as Historic. From rfc-ed@ISI.EDU Fri Nov 18 18:15:47 2005 X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: RFC Editor Cc: iesg@ietf.org, iana@iana.org From: IESG Secretary Date: Fri, 18 Nov 2005 21:13:56 -0500 X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Subject: Expedited Handling Request for 5 Documents Status: RO X-Lines: 27 Content-Type: text/plain Content-Length: 825 RFC Editor: 3GPP2 has requested through the liaison managers that we Fast Track some documents that are needed for reference in their X.P0022, X.P0011-D, X.P0028, and X.P0016-200 specifications. The deadline requirement is to make possible citing our RFCs in their specifications. Publication of all these documents is required on or before 20 December 2005. The documents are - 1) draft-ietf-tls-psk-09.txt 2) draft-ietf-mip6-mn-ident-option-03.txt 3) draft-gellens-mime-bucket-04.txt 4) draft-ietf-dhc-bcmc-options-05.txt 5) draft-ietf-mip6-auth-protocol-07.txt NOTE: For draft-ietf-dhc-bcmc-options-05.txt and draft-ietf-mip6-auth-protocol-07.txt, the IANA actions have not yet been completed, but the IANA has stated that it is possible to complete the actions in an expedited fashion as well. Thank you. The IESG From rfc-ed@ISI.EDU Wed Jan 4 17:15:39 2006 X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: RFC Editor Cc: iesg@ietf.org From: IESG Secretary Date: Wed, 04 Jan 2006 20:12:17 -0500 X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Subject: Expedited Handling Request for draft-ietf-avt-rtp-amrwbplus-07 Status: RO X-Lines: 10 Content-Type: text/plain Content-Length: 253 Dear RFC Editor: Please expedite the publication of draft-ietf-avt-rtp-amrwbplus-07.txt so that the RFC is announced by January 20. This is needed by the Digital Video Broadcast (DVB) Consortium for citation as a required codec. Thank you, The IESG From rfc-ed@ISI.EDU Thu Jan 5 13:55:57 2006 X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: IETF Announcement list Cc: iesg@ietf.org, rfc-editor@rfc-editor.org From: IESG Secretary Date: Thu, 05 Jan 2006 16:53:55 -0500 X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Subject: IESG Statement on AUTH48 state Status: RO X-Lines: 6 Content-Type: text/plain Content-Length: 297 The IESG has decided that as of now, any IESG-approved drafts that enter the AUTH48 state, where the RFC Editor waits for final text approval from all listed authors, may be released on the responsible AD's authority if any authors have not responded after a reasonable time, typically two weeks. From rfc-ed@ISI.EDU Wed Feb 1 12:34:11 2006 X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-test-idtracker: no From: The IESG To: RFC Editor Cc: The IESG , Date: Wed, 01 Feb 2006 15:30:47 -0500 X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Subject: Re: Informational RFC to be: draft-zenner-rabbit-02.txt Status: RO Content-Length: 1530 X-Lines: 45 The IESG has no problem with the publication of 'A Description of the Rabbit Stream Cipher Algorithm' 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=13038&r fc_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 Russ Housley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zenner-rabbit-02.txt Thank you, The IESG Secretary Technical Summary This document describes the Rabbit stream encryption algorithm, which uses 128-bit key and 64-bit IV. Working Group Summary This document is an individual submission. It is not affiliated with any IETF Working Group. Protocol Quality The document makes the algorithm description available to the Internet community. The document describes a patented stream cipher. The IPR Statement for this stream cipher was posted on 2 Dec 2005. 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 notes that the decision to publish is not based on IETF review apart from IESG review for conflict with IETF work. The RFC Editor has chosen to publish this document at its discretion. See RFC 3932 for more information. From rfc-ed@ISI.EDU Tue Feb 7 07:16:47 2006 X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-test-idtracker: no From: The IESG To: RFC Editor Cc: The IESG , Date: Tue, 07 Feb 2006 10:14:39 -0500 X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Subject: Re: Informational RFC to be: draft-kompella-ccc-02.txt Content-Length: 635 Status: RO X-Lines: 19 The IESG recommends that 'Circuit Cross-Connect' NOT be published as an an Informational RFC. The IESG contact person is Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kompella-ccc-02.txt Thank you, The IESG Secretary Proposed Recommendation to the RFC Editor, from RFC 3932: 3. The IESG thinks that publication is harmful to the IETF work done in the PWE3 WG and recommends not publishing the document at this time. If this document is published, it should be after the PWE3 standards track work. Also, there are significant editorial concerns. From rfc-ed@ISI.EDU Thu Feb 16 22:50:11 2006 X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-IronPort-AV: i="4.02,122,1139212800"; d="scan'208"; a="1777217589:sNHT39922072" Date: Fri, 17 Feb 2006 07:47:46 +0100 From: Mark Townsley User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en To: RFC Editor CC: Brian E Carpenter Subject: [Fwd: draft-kompella-ccc-02.txt] Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Status: RO X-Lines: 46 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Length: 1616 I am finishing up the response to your question of the IESG with respect to draft-kompella-ccc-02.txt. Brian suggested I forward you the email below directly. As stated, it was my understanding that the author of this document was going to withdraw his publication, and resubmit after the PWE3 Working Group finished its chartered items which overlap with this document. The mistake I made, was in not sending this on to you last July as I told Kireeti I would. That was an unfortunate oversight, and the reason the document sat untouched for so long (I had it in my head that it was back on your queue, which was definitely wrong). In any case, I have dug through old emails that led to the IESG's decision to ultimately send a do not publish for this document and included them in the tracker. A more formal response from the IESG should be coming soon. Thank you, and sorry for the confusion. I hope that, in the end, the final result is the same as it would have been had I followed up on this message in more appropriate course. - Mark -------- Original Message -------- Subject: draft-kompella-ccc-02.txt Date: Thu, 28 Jul 2005 09:31:33 +0200 From: Mark Townsley To: Kireeti Kompella CC: townsley@cisco.com Kireeti - just to be sure, I plan to send this to the RFC-Editor. I believe this is what we agreed on when we spoke. Editor, The author of draft-kompella-ccc-02.txt has agreed to withdraw submission of this document until after the PWE3 WG has completed overlapping work. I will shepherd the document at that time. Thank you, - Mark From rfc-ed@ISI.EDU Tue Feb 21 13:07:33 2006 X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SUBJ_HAS_SPACES,SUBJ_HAS_UNIQ_ID autolearn=no version=3.1.0 X-test-idtracker: no From: The IESG To: RFC Editor Cc: The IESG , Date: Tue, 21 Feb 2006 16:05:39 -0500 X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Subject: Re: Experimental RFC to be: draft-stiemerling-midcom-simco-08.txt Content-Length: 1967 Status: RO X-Lines: 48 The IESG has no problem with the publication of 'Simple Middlebox Configuration (SIMCO) Protocol Version 3.0' as an Experimental 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=8262&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 Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-stiemerling-midcom-simco-08.txt Thank you, The IESG Secretary Technical Summary Working Group Summary Protocol Quality This document was reviewed under RFC3932 rules by Jon Peterson. Note to RFC Editor Please include the following IESG Note boilerplate from RFC3932: The content of this RFC was at one time considered by the IETF, and therefore it may resemble a current IETF work in progress or a published IETF work. 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. Also, the IESG would like to note that this specification describes a protocol invented and implemented by the NEC Corporation. At its discretion, the RFC Editor might want to request that the authors reflect that that NEC Corporation is responsible for the protocol in the title of the specification. From rfc-ed@ISI.EDU Thu Mar 16 12:18:53 2006 X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SUBJ_HAS_SPACES,SUBJ_HAS_UNIQ_ID autolearn=no version=3.1.0 X-test-idtracker: no From: The IESG To: RFC Editor Cc: The IESG , Date: Thu, 16 Mar 2006 15:16:55 -0500 X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Subject: Re: Informational RFC to be: draft-white-pathconsiderations-05.txt Content-Length: 1356 Status: RO X-Lines: 42 The IESG has no problem with the publication of 'Considerations in Validating the Path in BGP' 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=11359&r fc_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 Alex Zinin. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-white-pathconsiderations-05.txt Thank you, The IESG Secretary Technical Summary This document reprents author's view on considerations related to BGP route path validation. Working Group Summary This document is an idvididual submission via RFC Editor. It has been referred to the RPSEC WG for a review. The WG has no objection to this document being published by the RFC Editor. Protocol Quality Not applicable. IESG Note: After consultation with the RPSEC WG, the IESG thinks that this work is related to IETF work done in WG RPSEC, but this does not prevent publishing. The IESG also recommends that a standard IESG note described in RFC 3932, section 4, case 2, is inserted in the document before publication. From rfc-ed@ISI.EDU Tue Mar 21 14:21:23 2006 X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 From: "Wijnen, Bert (Bert)" To: rfc-editor@rfc-editor.org, Saravanan Govindan Cc: dorothy.gellert@nokia.com, "Mani, Mahalingam (Mani)" , "Dan Romascanu (E-mail)" , "David Kessens (E-mail)" Subject: RE: Request for publication: draft-iino-capwap-wicop-02 Date: Tue, 21 Mar 2006 23:18:49 +0100 X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Status: RO X-Lines: 32 Content-Type: text/plain Content-Length: 994 RFC-Editor, Ideally this document gets published AS-IS, because the objective is to have a permanent archival record of the INPUT that was provided to the CAPWAP WG for evaluation. So it should be the content that was actually evaluated. Just so you know whey this one (and possibly 3 more) will be coming your way as independent submissions. Bert > -----Original Message----- > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > Sent: Tuesday, March 21, 2006 14:32 > To: rfc-editor@rfc-editor.org > Cc: dorothy.gellert@nokia.com; Mani, Mahalingam (Mani); Wijnen, Bert > (Bert); Dan Romascanu (E-mail); David Kessens (E-mail) > Subject: Request for publication: draft-iino-capwap-wicop-02 > > > RFC-Editor, > > I'd like to request draft-iino-capwap-wicop-02, titled "Wireless LAN > Control Protocol (WiCoP)", to be published in the Informational > category. > > The draft has been resurrected by the ADs of the CAPWAP WG. > > Thank you > > Saravanan Govindan > From rfc-ed@ISI.EDU Thu Mar 23 16:14:22 2006 X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 X-test-idtracker: no From: The IESG To: RFC Editor Cc: Date: Thu, 23 Mar 2006 19:12:53 -0500 X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Subject: Re: Informational RFC to be: draft-kompella-ccc-02.txt Content-Length: 3453 Status: RO X-Lines: 74 The IESG recommends that 'Circuit Cross-Connect' NOT be published as an an Informational RFC. The IESG contact person is Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kompella-ccc-02.txt RFC Editor: There are additional clarification comments regarding the do not publish recommendation in the I-D Tracker to address the questions raised on February 8, 2006. We apologise for the delay, there were some unanswered questions between the shepherding AD and the IESG Secretary. Thank you, The IESG Secretary RFC Editors Note: >From RFC 3932: 3. The IESG thinks that publication is harmful to the IETF work done in the PWE3 WG and recommends not publishing the document at this time. This document contains work which overlaps Standards Track work in PWE3. PWE3 has had a number of individual-submission documents to consider since its inception. Until the WG settled on a solution, any action that looked like a blessing of one approach over another could be seen as an end-run on the WG's work, despite disclaimers. Other authors of such proposals were asked to hold their work after PWE3 finished its Standards Track work, and they have complied.It would be wrong to treat the others unfairly by publishing one piece of overlapping work, and not another. PWE3 documents which should be published in advance of draft-kompella-ccc include: draft-ietf-pwe3-control-protocol draft-ietf-pwe3-frame-relay draft-ietf-pwe3-hdlc-ppp-encap-mpls draft-ietf-pwe3-ethernet-encap draft-ietf-pwe3-atm-encap There was previous agreement with the author of this document that it would be withdrawn until after PWE3 finished its chartered work. Niether the shepherding AD, nor the author of the document, followed up with the RFC Editor properly on this. This was a serious oversight, and the primary reason the document sat in queue for so long. In addition to the current conflict with PWE3, there have been substantive comments on this document with respect to its suitability for publication at anytime in its current form. These include: There are missing code-points in this specification. The values, if documented according to current implementation, would fall within an invalid range according to RSVP-Change procedures (RFC 3936) as they were originally chosen before such procedures existed. These should at least be made known and perhaps "grandfathered" one way or another - at a minimum IANA should mark these as "reserved" so that it does not inadverdantly hand them out in the future. The document needs an IANA Considerations section, detailing what IANA should do here, and a review that the RFC 3936 procedures have been met. The authors should be aware of this and the associated procedures, please see "IANA Considerations and RSVP Change procedures" for an account. Title or Abstract/Introduction should specifically mention that this was a single-vendor effort from Juniper, e.g., "Juniper Circuit Cross-Connect" The accuracy of the historical account included in this document has been called to question by at least one member of the community. Please see "Eric Rosen on Accuracy of Historical Account" in the tracker for details. The PWE3 Chairs have made a statement with respect to overlap of standards track work, and general suitability of this document for publication. Please see"Statement from PWE3 Working Group Chairs" in the tracker. From ietf-announce-bounces@ietf.org Thu Mar 30 15:25:47 2006 X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 To: IETF Announcement list From: IESG Secretary Date: Thu, 30 Mar 2006 18:24:04 -0500 X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: iesg@ietf.org List-Id: ietf-announce.ietf.org X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Subject: Reclassification of draft-ietf-idwg-beep-idxp-07 as an Experimental RFC Status: RO X-Lines: 13 Content-Type: text/plain; charset="utf-8" Content-Length: 668 The IESG has reclassified draft-ietf-idwg-beep-idxp, currently in the rfc-editor's queue as an experimental RFC. This document was originally approved as a proposed standard. However it contains a normative reference to draft-ietf-idwg-idmef-xml. That specification has been approved as an experimental RFC not as a standards-track document. So, in order to avoid a normative reference from a standards track document to an experimental document, the IESG has chosen to reclassify the IDXP protocol as experimental. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce From braden@ISI.EDU Tue Apr 4 12:36:41 2006 X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 From: Bob Braden Date: Tue, 4 Apr 2006 12:35:33 -0700 (PDT) To: kireeti@juniper.net, john.ospina@cingular.com, shilpa.kamdar@cingular.com, jeff_richmond@eli.net, Gregory.J.Miller@MCI.com Subject: [ISR-REV] draft-kompella-ccc-02.txt Cc: rfc-editor@rfc-editor.org, rfc-ed-board@rfc-editor.org X-ISI-4-43-8-MailScanner: Found to be clean Content-Length: 4437 Status: RO X-Lines: 104 Authors, We regret to inform you that the IESG has recommended against publication of your document as a direct conflict with the PWE3 working group. Their comments are appended below. The RFC Editor must accept this recommendation, and we are removing your document from our queue. It may be possible to publish it after the PWE3 working group has completed its work, but we suggest that you check with the relevant ADs before resubmitting it. RFC Editor/bb ----- Begin Included Message ----- >From rfc-ed@ISI.EDU Thu Mar 23 16:14:22 2006 X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 X-test-idtracker: no From: The IESG To: RFC Editor Cc: Date: Thu, 23 Mar 2006 19:12:53 -0500 X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Subject: Re: Informational RFC to be: draft-kompella-ccc-02.txt The IESG recommends that 'Circuit Cross-Connect' NOT be published as an an Informational RFC. The IESG contact person is Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kompella-ccc-02.txt RFC Editor: There are additional clarification comments regarding the do not publish recommendation in the I-D Tracker to address the questions raised on February 8, 2006. We apologise for the delay, there were some unanswered questions between the shepherding AD and the IESG Secretary. Thank you, The IESG Secretary RFC Editors Note: >From RFC 3932: 3. The IESG thinks that publication is harmful to the IETF work done in the PWE3 WG and recommends not publishing the document at this time. This document contains work which overlaps Standards Track work in PWE3. PWE3 has had a number of individual-submission documents to consider since its inception. Until the WG settled on a solution, any action that looked like a blessing of one approach over another could be seen as an end-run on the WG's work, despite disclaimers. Other authors of such proposals were asked to hold their work after PWE3 finished its Standards Track work, and they have complied.It would be wrong to treat the others unfairly by publishing one piece of overlapping work, and not another. PWE3 documents which should be published in advance of draft-kompella-ccc include: draft-ietf-pwe3-control-protocol draft-ietf-pwe3-frame-relay draft-ietf-pwe3-hdlc-ppp-encap-mpls draft-ietf-pwe3-ethernet-encap draft-ietf-pwe3-atm-encap There was previous agreement with the author of this document that it would be withdrawn until after PWE3 finished its chartered work. Niether the shepherding AD, nor the author of the document, followed up with the RFC Editor properly on this. This was a serious oversight, and the primary reason the document sat in queue for so long. In addition to the current conflict with PWE3, there have been substantive comments on this document with respect to its suitability for publication at anytime in its current form. These include: There are missing code-points in this specification. The values, if documented according to current implementation, would fall within an invalid range according to RSVP-Change procedures (RFC 3936) as they were originally chosen before such procedures existed. These should at least be made known and perhaps "grandfathered" one way or another - at a minimum IANA should mark these as "reserved" so that it does not inadverdantly hand them out in the future. The document needs an IANA Considerations section, detailing what IANA should do here, and a review that the RFC 3936 procedures have been met. The authors should be aware of this and the associated procedures, please see "IANA Considerations and RSVP Change procedures" for an account. Title or Abstract/Introduction should specifically mention that this was a single-vendor effort from Juniper, e.g., "Juniper Circuit Cross-Connect" The accuracy of the historical account included in this document has been called to question by at least one member of the community. Please see "Eric Rosen on Accuracy of Historical Account" in the tracker for details. The PWE3 Chairs have made a statement with respect to overlap of standards track work, and general suitability of this document for publication. Please see"Statement from PWE3 Working Group Chairs" in the tracker. ----- End Included Message ----- From rfc-ed@ISI.EDU Mon May 8 08:51:27 2006 X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SUBJ_HAS_SPACES,SUBJ_HAS_UNIQ_ID autolearn=no version=3.1.0 X-test-idtracker: no From: The IESG To: RFC Editor Cc: The IESG , Date: Mon, 08 May 2006 11:49:17 -0400 X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Subject: Re: Experimental RFC to be: draft-manning-opcode-discover-02.txt Content-Length: 1675 Status: RO X-Lines: 52 The IESG recommends that 'DISCOVER: Supporting Multicast DNS Queries' NOT be published as an an Experimental RFC. The IESG contact person is Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-manning-opcode-discover-02.txt Thank you, The IESG Secretary Technical Summary This document describes the DISCOVER opcode, an experimental extension to the Domain Name System (DNS) to use multicast queries for resource discovery. A client multicasts a DNS query using the DISCOVER opcode and processes the multiple responses that may result. Working Group Summary This document is an RFC Editor individual submission. The suggested response to the RFC Editor is included below. Protocol Quality This document was reviewed for the IESG by Margaret Wasserman. RFC Editor Note Dear RFC Editor, According to RFC 2929, DNS opcodes may only be allocated based on IETF Standards Action. It is therefore inappropriate to allocate a DNS opcode for an RFC Editor individual submission or any Experimental RFC. Based on this fact, the IESG is returning the following response to this document: 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. Please do not publish this document as an RFC through the RFC Editor individual submission path. In the event that the RFC Editor does decide to publish this document in the future, the IESG will want to include an IESG note. Thank you. From rfc-ed@ISI.EDU Mon Sep 18 13:56:00 2006 X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SUBJ_HAS_SPACES,SUBJ_HAS_UNIQ_ID autolearn=no version=3.1.0 X-test-idtracker: no From: The IESG To: RFC Editor Cc: The IESG , Date: Mon, 18 Sep 2006 16:55:02 -0400 X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Subject: Re: Informational RFC to be: draft-murphy-iser-telnet-04.txt Status: RO Content-Length: 1209 X-Lines: 30 The IESG has no problem with the publication of 'iSeries Telnet Enhancements' 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=10479&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 Ted Hardie. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-murphy-iser-telnet-04.txt Thank you, The IESG Secretary 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. From rfc-ed@ISI.EDU Mon Sep 25 11:25:12 2006 X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 From: "Lisa Dusseault via RT" X-RT-Loop-Prevention: Inquiry RT-Ticket: Inquiry #88619 Managed-by: RT 3.2.1 (http://www.bestpractical.com/rt/) RT-Originator: lisa@osafoundation.org To: rfc-editor@rfc-editor.org X-RT-Original-Encoding: utf-8 Date: Mon, 25 Sep 2006 14:23:29 -0400 X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Subject: Re: [Inquiry #88619] draft-kunze-rfc2413bis-04.txt Status: RO X-Lines: 79 Content-Type: text/plain; charset="utf-8" Content-Length: 2625 This one's easy; Ted's on vacation, I know something about Dublin Core and RFC2413, so I'll take it. I assume in this case that means OK'ing it for publication by the RFC Editor. I am OK with that as we don't have any groups working on this topic, and it seems generally a good thing to replace the IETF's official Dublin Core metadata reference with updated information from the same source. BTW, there are 3 RFCs which refer to RFC2413 already. - RFC2518, WebDAV: just a reference, no functional dependency at all. - RFC3023, XML Media Types : same - RFC2731, encoding Dublin Core metadata in HTML: This is by the same author as RFC2413bis so I assume he knows the implications. Although none of these dependencies seems likely to create a problem, is it possible to ask that the WebDAV and XML-Directorate lists be informed of this publication early on in the process? These would also be good places to find expert reviewers. Lisa On Sep 25, 2006, at 3:31 AM, via RT wrote: > Dear Brian: > > The following Internet-Draft, which was received from the RFC Editor > on September 15, has been added to the I-D Tracker listing you as the > Shepherding AD: > > draft-kunze-rfc2413bis-04.txt > > The I-D has also been placed on the Agenda for the next IESG Telechat > so that the I-D can be assigned to an appropriate AD. > > The IETF Secretariat > > > >> [rfc-editor@rfc-editor.org - Fri Sep 15 19:54:33 2006]: >> >> IESG, >> >> This RFC-to-be was submitted to the RFC Editor to be published as >> Informational: draft-kunze-rfc2413bis-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 (13 October 2006). >> >> >> The Dublin Core Metadata Element Set >> >> The Dublin Core Metadata Workshop Series began in 1995 with an >> invitational workshop which brought together librarians, digital >> library researchers, content experts, and text-markup experts to >> promote better discovery standards for electronic resources. The >> resulting metadata element set is perhaps the most widely adopted >> convention for structuring resource descriptions designed to > bridge >> networked information systems and content providers in the >> publishing, library, museum, scholarly, archival, and government >> communities. It defines fifteen metadata elements for resource >> description in a cross-disciplinary information environment. >> >> >> >> Sincerely, >> >> Sandy Ginoza - USC/ISI >> Request for Comments Documents >> >> >> > > From rfc-ed@ISI.EDU Mon Oct 2 13:57:38 2006 X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SUBJ_HAS_SPACES,SUBJ_HAS_UNIQ_ID autolearn=no version=3.1.0 X-test-idtracker: no From: The IESG To: RFC Editor Cc: The IESG , Date: Mon, 02 Oct 2006 16:56:35 -0400 X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Subject: Re: Informational RFC to be: draft-shirey-secgloss-v2-07.txt Status: RO Content-Length: 2617 X-Lines: 64 The IESG has no problem with the publication of 'Internet Security Glossary, Version 2' 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=12238&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 Russ Housley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shirey-secgloss-v2-07.txt Thank you, The IESG Secretary Technical Summary This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. It is very long (300+ pages). It offers recommendations to improve the clarity of Internet documents. The recommendations follow the principles that Internet documents should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. Working Group Summary This is an individual effort. It is not affiliated with any IETF Working Group. Protocol Quality The Security Directorate helped review this document. Each member was assigned the task of reviewing several pages of the document. The intent was to make sure that someone other than the author had looked at each definition. Comments were provided by each reviewer; however, there was no attempt to reach consensus on each definition. This document was reviewed by Russ Housley for the IESG. 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 notes that the decision to publish is not based on IETF review apart from IESG review for conflict with IETF work. The RFC Editor has chosen to publish this document at its discretion. See RFC 3932 for more information. Note to the RFC Editor The Abstract and the Introduction of this document include prescriptive language that is more appropriate in a BCP. The IESG strongly encourages the RFC Editor to work with the author to come up with wording that does not imply an IETF concensus on the definitions in this document. From rfc-ed@ISI.EDU Wed Oct 4 10:49:01 2006 X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Subject: Re: [Inquiry #88747] Informational RFC-to-be: draft-levis-meta-qos-class-00.txt From: "Bob Braden via RT" X-RT-Loop-Prevention: Inquiry RT-Ticket: Inquiry #88747 Managed-by: RT 3.2.1 (http://www.bestpractical.com/rt/) RT-Originator: braden@ISI.EDU To: rfc-editor@rfc-editor.org X-RT-Original-Encoding: utf-8 Date: Wed, 04 Oct 2006 13:48:00 -0400 X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Status: RO X-Lines: 25 Content-Type: text/plain; charset="utf-8" Content-Length: 713 *> *> Dear Brian: *> *> The following Internet-Draft, which was received from the RFC Editor *> on September 25th, has been added to the I-D Tracker listing you as *> the Shepherding AD: *> *> draft-levis-meta-qos-class-00.txt *> *> The I-D has also been placed on the Agenda for the next IESG Telechat *> so that the I-D can be assigned to an appropriate AD. *> *> The IETF Secretariat *> *> The RFC Editor has received additional input from the Editorial Board that calls into question the wisdom of our decision to publish this document. We therefore wish to withdraw it from TO state at this time. We apologize for any inconvenience this caused. RFC Editor/bb From rfc-ed@ISI.EDU Wed Jan 24 14:07:49 2007 X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=3.1.0 To: RFC Editor From: Lisa Dusseault Subject: draft-kunze-rfc2413bis-04.txt Date: Wed, 24 Jan 2007 14:06:39 -0800 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Content-Type: multipart/alternative; boundary="Apple-Mail-8-243154918" Status: RO X-Lines: 30 Content-Length: 2800 --Apple-Mail-8-243154918 Content-Type: text/plain; charset="us-ascii"; delsp="yes"; format="flowed" X-Sun-Content-Length: 589 This draft is proposing to update an RFC that has a number of other RFCs referring to it. For that reason, I would like it to go through IETF last call and be reviewed by Apps area experts. I volunteered to handle that and I'm unsure now about the status of the document or how to clear up the inconsistency Bill noted. Thanks, Lisa Begin forwarded message: > > category INDEPENDENT SUBMISSIONS UNDER RFC EDITOR REVIEW (by date > received) > > Document: draft-kunze-rfc2413bis-04.txt > Datatracker: Publication Requested ~~ AD Followup (2006-11-02) > RFC Editor: ISR-AUTH --Apple-Mail-8-243154918 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Sun-Content-Length: 1912

This draft is proposing to = update an RFC that has a number of other RFCs referring to it.=A0 For = that reason, I would like it to go through IETF last call and be = reviewed by Apps area experts.=A0 I volunteered to handle that and I'm = unsure now about the status of the document or how to clear up the = inconsistency Bill noted.

Thanks,
Lisa

Begin forwarded message:


=A0category = INDEPENDENT SUBMISSIONS UNDER RFC EDITOR REVIEW (by date = received)


Document: = draft-kunze-rfc2413bis-04.txt

Datatracker: = Publication Requested ~~ AD Followup (2006-11-02)

RFC Editor: = ISR-AUTH


= --Apple-Mail-8-243154918-- From lisa@osafoundation.org Wed Jan 24 15:25:17 2007 X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: IESG taking over draft-kunze-rfc2413bis-03+.txt Date: Wed, 24 Jan 2007 15:24:20 -0800 To: Bob Braden X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Content-Length: 2712 Status: RO X-Lines: 82 thanks, that's great. I believe that putting the document into WITHDRAWN status in your database, will remove the inconsistency with the IESG database that Bill Fenner noted. I do look forward to working with the author, as you say he's been working with determination and I can definitely facilitate him finishing this work. Lisa On Jan 24, 2007, at 3:08 PM, Bob Braden wrote: > > *> From rfc-ed@ISI.EDU Wed Jan 24 14:07:49 2007 > *> X-Spam-Status: No, score=-2.6 required=5.0 > tests=AWL,BAYES_00,HTML_MESSAGE > *> autolearn=ham version=3.1.0 > *> To: RFC Editor > *> From: Lisa Dusseault > *> Subject: Fwd: 2007-01-23 report of possible IESG/RFC-Editor > inconsistencies > *> Date: Wed, 24 Jan 2007 14:06:39 -0800 > *> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org > *> X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean > *> > *> > *> This draft is proposing to update an RFC that has a number of > other > *> RFCs referring to it. For that reason, I would like it to go > through > *> IETF last call and be reviewed by Apps area experts. I > volunteered > *> to handle that and I'm unsure now about the status of the > document or > *> how to clear up the inconsistency Bill noted. > *> > *> Thanks, > *> Lisa > > Lisa, > > That's fine with the RFC Editor, as long as it gets published somehow. > The author has worked with remarkable determination over a long time. > Here is my log on the document: > > > draft-kunze-rfc2413bis-02.txt > 20020509 ISR -01 > 20030825 DNP-AUTH -- talked to Ted Hardie > 20040818 REPL -02 > 20050426 Q to author > 20050507 Also 11, 18: replies from author > 20050621 ISR-AUTH Ask for revision > 20050721 ISR -03 > 20060218 ISR-AUTH Msg to author -- request more changes > 20060829 ISR -04 > 20060914 TO -04 > 20061003 ISR-AUTH: author wants to revise. Pulled from TO state. > 20061218 ISR -05 > 20070104 Comments to author from Alfred H. > 20070112 "we're close" > 20070124 Request from Lisa Dusseault to pull into IESG > > > I am not awarwe of the "inconsistency that Bill noted". AFAIK, > Kunze wanted to update the document, and therefore we pulled it from > TO state (IESG RFC 3932 consideration) in Oct 2006 (see above). > Just last week the author told me they are "real close" to having > a new, hopefully final, version. > > I guess you need to talk directly to John Kunze about status. > Assuming that you plan to take over the document, we will put it > into WITHDRAWN status. > > Let us know if you have any other questions. > > RFC Editor/bb > > ----- End Included Message ----- From rcallon@juniper.net Thu Jan 25 12:51:25 2007 X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Sender: rcallon@zircon.juniper.net Date: Thu, 25 Jan 2007 15:49:40 -0500 To: fenner@research.att.com, braden@ISI.EDU From: Ross Callon Subject: draft-deoliveira-diff-te-preemption-06 Cc: brc@zurich.ibm.com, rcallon@juniper.net X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Status: RO X-Lines: 24 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Length: 508 The IESG discussed draft-deoliveira-diff-te-preemption-06 during the telechat today. Based on the recent update to the document and CCAMP review, there is now no objection to publishing it, and a recommendation from the shepherding AD (me) to publish it as an individual submission. I am not sure what I am supposed to do in the ID Tracker to handle this case. The current state is "IESG Evaluation", but this should be updated. Should I change this to "Approved -- announcement to be sent". Thanks, Ross From ietf-announce-bounces@ietf.org Mon Jan 29 14:39:35 2007 X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 X-test-idtracker: no From: The IESG To: RFC Editor Date: Mon, 29 Jan 2007 17:38:09 -0500 X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: iana@iana.org, The IESG , ietf-announce@ietf.org List-Id: ietf-announce.ietf.org X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Subject: Re: Informational RFC to be: draft-zorn-radius-keywrap-12.txt Content-Length: 1265 Status: RO X-Lines: 46 The IESG recommends that 'RADIUS Attributes for the Delivery of Keying Material' NOT be published as an an Informational RFC. The IESG contact person is Russ Housley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-12.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 defines a set of RADIUS Attributes designed to allow both the secure transmission of cryptographic keying material and strong authentication of any RADIUS message. Working Group Summary This document is not the result of any IETF Working Group. It is an individual submission to the RFC Editor. Protocol Quality This document is being shepherded through the IESG review process by Russ Housley. Note to RFC Editor 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. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ----- End Included Message ----- From braden@ISI.EDU Tue Jan 30 10:41:55 2007 X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 From: Bob Braden Date: Tue, 30 Jan 2007 10:41:06 -0800 (PST) To: zow@acm.org, braden@ISI.EDU Subject: Re: draft-brugger-connection-metrics-01.txt Cc: rfc-editor@rfc-editor.org, rfc-ed-board@rfc-editor.org X-ISI-4-43-8-MailScanner: Found to be clean Content-Length: 181 Status: RO X-Lines: 8 S. Terry Brugger: Since you have not responded to our warning message of Jan 11, 2007, we must now reject your independent submission and remove it from our queue. RFC Editor/bb From braden@ISI.EDU Tue Jan 30 15:23:42 2007 X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 From: Bob Braden Date: Tue, 30 Jan 2007 15:22:41 -0800 (PST) To: housley@vigilsec.com Subject: draft-zorn-radius-keywrap-12.txt Cc: rfc-ed-board@rfc-editor.org, gwz@cisco.com, brc@zurich.ibm.com X-ISI-4-43-8-MailScanner: Found to be clean Content-Length: 1904 Status: RO X-Lines: 65 ----- Begin Included Message ----- Russ, We would infer from this message that the IESG in general and you in particular has now volunteered to accept and shepherd this document as an individual (IESG) submission. Please confirm that this is the case, so we can inform the author and remove the document from the RFC Editor's independent submission queue. Thanks, RFC Editor/bb ____________________________________________________________________ From: The IESG To: RFC Editor Cc: The IESG , , ietf-announce@ietf.org Date: Mon, 29 Jan 2007 17:38:09 -0500 X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Subject: Re: Informational RFC to be: draft-zorn-radius-keywrap-12.txt The IESG recommends that 'RADIUS Attributes for the Delivery of Keying Material' NOT be published as an an Informational RFC. The IESG contact person is Russ Housley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-12.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 defines a set of RADIUS Attributes designed to allow both the secure transmission of cryptographic keying material and strong authentication of any RADIUS message. Working Group Summary This document is not the result of any IETF Working Group. It is an individual submission to the RFC Editor. Protocol Quality This document is being shepherded through the IESG review process by Russ Housley. Note to RFC Editor 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. ----- End Included Message ----- From ietf-announce-bounces@ietf.org Wed Jan 31 07:10:16 2007 X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 X-test-idtracker: no From: The IESG To: RFC Editor Date: Wed, 31 Jan 2007 10:07:31 -0500 X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: iana@iana.org, The IESG , ietf-announce@ietf.org List-Id: ietf-announce.ietf.org X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Subject: Re: Informational RFC to be: draft-irtf-dtnrg-arch-08.txt Status: RO Content-Length: 2165 X-Lines: 66 The IESG has no problem with the publication of 'Delay-Tolerant Networking Architecture' 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=10157&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 Lars Eggert. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-arch-08.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 describes an architecture for delay and disruption tolerant networks. The document is a product of the IRTF delay tolerant networking research group (see http://www.dtnrg.org) Working Group Summary This is an IRTF document being advanced according to draft-irtf-rfcs-00.txt. The DTNRG have expressed support for publishing this with no dissent. Protocol Quality The IRSG reviewed this leading to comments being resolved (see IRTF tracker [1]). There are no implementations since this is an architecture, though there are implementations of some protocols adhering to the architecture (which will trundle along this way sometime this year) [1] http://www1.tools.ietf.org/group/irtf/trac/ticket/6 Note to RFC Editor Add this sentence to the end of the abstract: This document represents the consensus of the IRTF DTN research group and has been widely reviewed by that group. IESG Note 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 on the public Internet. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce From rfc-ed@ISI.EDU Wed Jan 31 07:11:03 2007 X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SUBJ_HAS_SPACES,SUBJ_HAS_UNIQ_ID autolearn=no version=3.1.0 X-test-idtracker: no From: The IESG To: RFC Editor Cc: The IESG , , ietf-announce@ietf.org Date: Wed, 31 Jan 2007 10:09:34 -0500 X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Subject: Re: Informational RFC to be: draft-deoliveira-diff-te-preemption-06.txt Status: RO Content-Length: 3043 X-Lines: 72 The IESG has no problem with the publication of 'LSP Preemption Policies for MPLS Traffic Engineering' 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=10018&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-deoliveira-diff-te-preemption-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 the establishment of a higher priority Traffic Engineering Label Switched Path requires the preemption of a set of lower priority TE LSPs, a node has to make a local decision to select which TE LSPs will be preempted. The preempted LSPs are then rerouted by their respective Head-end Label Switch Router. This document presents a flexible policy that can be used to achieve a variety of objectives when LSPs are preempted. Simulation results are given and a comparison among several different policies is also included. Working Group Summary This is an individual submission via the RFC editor. Protocol Quality Ross Callon has reviewed this spec. The document, while an individual submission, was referred to the CCAMP working group for progression. Using the terms from section 3 of 3932, historically the reason was: 5. The IESG thinks that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. At this point the document has been updated based on detailed comments by the CCAMP co-chair, updated, and last called in the CCAMP working group. Last call comments have been resolved. We believe that the status should now be: 2. The IESG thinks that this work is related to IETF work done in WG CCAMP, but this does not prevent publishing. Note to RFC Editor We believe that having been successfully updated, and then reviewed in CCAMP, the document is now ready to be published. Given that this is still an individual submission, we believe that the proper note to specify its status would be: 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. From gwz@cisco.com Wed Jan 31 11:16:54 2007 X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 X-IronPort-AV: i="4.13,263,1167638400"; d="scan'208"; a="358722952:sNHT51704616" Content-class: urn:content-classes:message Subject: RE: draft-zorn-radius-keywrap-12.txt Date: Wed, 31 Jan 2007 11:16:25 -0800 Thread-Topic: draft-zorn-radius-keywrap-12.txt From: "Glen Zorn \(gwz\)" To: "Brian E Carpenter" Cc: "Russ Housley" , "Bob Braden" , , "Glen Zorn \(gwz\)" DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3778; t=1170270995; x=1171134995; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20draft-zorn-radius-keywrap-12.txt |Sender:=20; bh=BaXhA+i5D4alpoS61HEboYBudYQCEEdNnyxY98/pRMA=; b=nasgHzMdJNjjKdJVAhmBiJlmmszSg8M2X3S2iarYPcnJZf9AqEoUsqHrFWf0zMfOVUcXsYeO 5sCy5aPKtfAQeNoq9kEZdHbFuvrblz1vi2Es0zepj9fs1ni5Wgo0LY+/; Authentication-Results: sj-dkim-2; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); X-ISI-4-43-8-MailScanner: Found to be clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id l0VJGZmh006763 Status: RO X-Lines: 107 Content-Type: text/plain; charset="us-ascii" Content-Length: 3634 Brian E Carpenter allegedly scribbled on Wednesday, January 31, 2007 1:03 AM: > So, I suggest a discussion between Russ, Glen and the RADEXT chairs > is needed ASAP. That's fine w/me. I would like to reiterate that in this case I am just the document editor, so the participation of my co-authors and/or key contributors may be required. > > Indeed, the words in the formal reply are prescribed by > 3932 - the Discuss comments in the tracker explain the issues (it > updates a standards track document, and needs IANA assignments that > require IETF consensus). > > Brian > > On 2007-01-31 04:19, Glen Zorn (gwz) wrote: >> Russ Housley allegedly scribbled on >> Tuesday, January 30, 2007 4:19 PM: >> >>> No, this is not the case. The document ought to go through the >>> RADEXT WG. >> >> I agree with that -- in fact it should have been in radext at least 3 >> years ago, but the chairs that WG has refused to even respond to >> queries WRT that possibility. The closest thing they came to doing >> so was a short discussion on the mailing list. A long time later, >> Dave Nelson claimed that 'questions were raised that were not >> responded to', however that is untrue: the questions were, in fact, >> answered on the list -- just not by me. >> >>> Russ >>> >>> >>> At 06:22 PM 1/30/2007, Bob Braden wrote: >>> >>>> ----- Begin Included Message ----- >>>> >>>> >>>> Russ, >>>> >>>> We would infer from this message that the IESG in general and you >>>> in particular has now volunteered to accept and shepherd this >>>> document as an individual (IESG) submission. Please confirm that >>>> this is the case, so we can inform the author and remove the >>>> document from the RFC Editor's independent submission queue. >>>> >>>> Thanks, >>>> >>>> RFC Editor/bb >>>> >>>> ____________________________________________________________________ >>>> >>>> From: The IESG >>>> To: RFC Editor >>>> Cc: The IESG , , >>>> ietf-announce@ietf.org >>>> Date: Mon, 29 Jan 2007 17:38:09 -0500 >>>> X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean >>>> Subject: Re: Informational RFC to >>>> be: draft-zorn-radius-keywrap-12.txt >>>> >>>> The IESG recommends that 'RADIUS Attributes for the Delivery of >>>> Keying Material' NOT be >>>> published as an an Informational RFC. >>>> >>>> The IESG contact person is Russ Housley. >>>> >>>> A URL of this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-12.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 defines a set of RADIUS Attributes designed to >>>> allow both the secure transmission of cryptographic keying >>>> material and strong authentication of any RADIUS message. >>>> >>>> Working Group Summary >>>> >>>> This document is not the result of any IETF Working Group. It is >>>> an individual submission to the RFC Editor. >>>> >>>> Protocol Quality >>>> >>>> This document is being shepherded through the IESG review >>>> process by Russ Housley. >>>> >>>> Note to RFC Editor >>>> >>>> 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. >>>> >>>> >>>> ----- End Included Message ----- From david.burke@voxpilot.com Wed Feb 7 10:26:40 2007 From: "Dave Burke" To: Cc: "RJ Auburn" , "McGlashan, Scott" , "Mark Scott" , "Jeff Haynie" Subject: Re: Submission for RFC in the Informational category -> Withdrawal Date: Wed, 7 Feb 2007 19:36:19 -0000 X-Lines: 82 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 2519 Dear RFC Editor, Further to a conversation with the IESG, we would like to withdraw this I-D from the RFC queue at this time. We intend to instead pursue this through the new MediaCtrl working group. Kind regards, Dave ----- Original Message ----- From: "Dave Burke" To: Cc: "Jeff Haynie" ; "RJ Auburn" ; "McGlashan, Scott" ; "Mark Scott" Sent: Tuesday, July 18, 2006 10:43 AM Subject: Submission for RFC in the Informational category >Dear RFC Editor, > >We would like to request that the Internet-Draft "SIP Interface to >VoiceXML >Media Services" >(http://www.ietf.org/internet-drafts/draft-burke-vxml-01.txt >and attached in XML form) be considered as an RFC in the Informational >category. > >VoiceXML is a W3C standard that now dominates the Interactive >Voice Response (IVR) industry as the preferred paradigm for authoring >applications ranging from simple touch-tone interfaces through to advanced >speech applications and services incorporating interactive video. SIP is >becoming increasingly popular as a telephony interface to IVR services, >fuelled not least by next-generation network architectures. This >Internet-Draft specifies a SIP interface to VoiceXML services that is >based >upon a "cherry picking" of several closely related but previously >non-identical and non-published interfaces widely implemented by >leading companies in this space. > >The Internet-Draft has received wide review (evident by the list of >contributors, for example) and pointers to it supplied to the IETF SIPPING >WG and W3C Voice Browser Working Group (VBWG). Comments from these groups >have been processed in the latest available revision. The authors are >members of the W3C VBWG (though this does not represent any "official" W3C >submission). We believe the Internet-Draft is both sufficiently mature and >of sufficient interest to the wider Internet community to be published as >an >Informational RFC. > >Kind regards, > >Dave Burke, Mark Scott, Jeff Haynie, RJ Auburn, S. Mc Glashan > >----------------------------------------------------------------- >Dave Burke PhD > >Chief Technology Officer >Voxpilot Ltd >6 - 9 Trinity Street >Dublin 2 >Ireland > >Mobile: +353 86 6055086 >Office (Dublin): +353 1 2091922 >E-mail: david.burke@voxpilot.com >----------------------------------------------------------------- > ----- End forwarded message ----- From rfc-ed@ISI.EDU Tue Feb 13 12:55:27 2007 X-Spam-Status: No, score=-19.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_DEF_WHITELIST autolearn=ham version=3.1.0 Date: Tue, 13 Feb 2007 12:50:56 -0800 From: RFC Editor To: IESG , iesg-secretary Cc: RFC Editor , Marc.Blanchet@hexago.com, Florent.Parent@hexago.com Subject: Experimental RFC to be: draft-blanchet-v6ops-tunnelbroker-tsp-03.txt User-Agent: Mutt/1.4.1i X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Status: RO X-Lines: 34 Content-Type: text/plain; charset="us-ascii" Content-Length: 1270 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 rfc-ed@ISI.EDU Tue Feb 13 15:08:00 2007 X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Cc: Ted Hardie Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: IESG taking over draft-kunze-rfc2413bis-03+.txt Date: Tue, 13 Feb 2007 15:06:28 -0800 To: RFC Editor X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Status: RO X-Lines: 98 Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed" Content-Length: 3239 Hi, This document should certainly go through an IETF last call, because there are some Proposed Standards that depend on it; the people interested in those need a chance to comment on the changes. So I believe it's correct to change this to be AD-sponsored and remove it from your queue. Lisa On Feb 13, 2007, at 12:42 PM, RFC Editor wrote: > Hi Lisa, > > Could you please help us sort out the status of > ? > > We have this document listed in our queue as an independent submission > in the ISR-AUTH state. However, it sounds as though performing a last > call would change this to be an AD sponsored individual submission. > Is this true? If so, we will remove it from our queue until we > receive the document action from the IESG secretary. > > Thanks, > > RFC Editor > > > On Wed, Jan 24, 2007 at 03:08:30PM -0800, Bob Braden wrote: >> >> *> From rfc-ed@ISI.EDU Wed Jan 24 14:07:49 2007 >> *> X-Spam-Status: No, score=-2.6 required=5.0 >> tests=AWL,BAYES_00,HTML_MESSAGE >> *> autolearn=ham version=3.1.0 >> *> To: RFC Editor >> *> From: Lisa Dusseault >> *> Subject: Fwd: 2007-01-23 report of possible IESG/RFC-Editor >> inconsistencies >> *> Date: Wed, 24 Jan 2007 14:06:39 -0800 >> *> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org >> *> X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean >> *> >> *> >> *> This draft is proposing to update an RFC that has a number of >> other >> *> RFCs referring to it. For that reason, I would like it to go >> through >> *> IETF last call and be reviewed by Apps area experts. I >> volunteered >> *> to handle that and I'm unsure now about the status of the >> document or >> *> how to clear up the inconsistency Bill noted. >> *> >> *> Thanks, >> *> Lisa >> >> Lisa, >> >> That's fine with the RFC Editor, as long as it gets published >> somehow. >> The author has worked with remarkable determination over a long time. >> Here is my log on the document: >> >> >> draft-kunze-rfc2413bis-02.txt >> 20020509 ISR -01 >> 20030825 DNP-AUTH -- talked to Ted Hardie >> 20040818 REPL -02 >> 20050426 Q to author >> 20050507 Also 11, 18: replies from author >> 20050621 ISR-AUTH Ask for revision >> 20050721 ISR -03 >> 20060218 ISR-AUTH Msg to author -- request more >> changes >> 20060829 ISR -04 >> 20060914 TO -04 >> 20061003 ISR-AUTH: author wants to revise. Pulled from TO state. >> 20061218 ISR -05 >> 20070104 Comments to author from Alfred H. >> 20070112 "we're close" >> 20070124 Request from Lisa Dusseault to pull into IESG >> >> >> I am not awarwe of the "inconsistency that Bill noted". AFAIK, >> Kunze wanted to update the document, and therefore we pulled it from >> TO state (IESG RFC 3932 consideration) in Oct 2006 (see above). >> Just last week the author told me they are "real close" to having >> a new, hopefully final, version. >> >> I guess you need to talk directly to John Kunze about status. >> Assuming that you plan to take over the document, we will put it >> into WITHDRAWN status. >> >> Let us know if you have any other questions. >> >> RFC Editor/bb >> From rfc-ed@ISI.EDU Fri Feb 23 12:50:33 2007 X-Spam-Status: No, score=-19.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_DEF_WHITELIST autolearn=ham version=3.1.0 Date: Fri, 23 Feb 2007 12:48:35 -0800 From: RFC Editor To: IESG , iesg-secretary Cc: RFC Editor , rhboivie@us.ibm.com, nkfeldman@yahoo.com, kimai@flab.fujitsu.co.jp, WLivens@colt-telecom.be, dirk@onesparrow.com, Olivier.Paridaens@alcatel.be, muramoto.eiichi@jp.panasonic.com Subject: Experimental RFC-to-be: draft-ooms-xcast-basic-spec-11.txt User-Agent: Mutt/1.4.1i X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Status: RO X-Lines: 35 Content-Type: text/plain; charset="us-ascii" Content-Length: 1277 IESG, This RFC-to-be was submitted to the RFC Editor to be published as Experimental: draft-ooms-xcast-basic-spec-11.txt. Please let us know if this document conflicts with the IETF standards process or other work being done in the IETF community. This document was reviewed by Joel Halpern and by the RFC Editor, and it has undergone 3 revisions as a result. Five week timeout expires on 30 March 2007. (Please note we have included an additional week because of the upcoming IETF.) Explicit Multicast (Xcast) Concepts and Options While traditional IP multicast schemes [1112] are scalable for very large multicast groups, they have scalability issues with a very large number of distinct multicast groups. This document describes Xcast (Explicit Multi-unicast (Xcast)), a new multicast scheme with complementary scaling properties: Xcast supports a very large number of small multicast sessions. Xcast achieves this by explicitly encoding the list of destinations in the data packets, instead of using a multicast group address. This document discusses Xcast concepts and options in several areas; it does not provide a complete technical specification. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents From rfc-ed@ISI.EDU Mon Feb 26 20:21:34 2007 X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SUBJ_HAS_SPACES,SUBJ_HAS_UNIQ_ID autolearn=no version=3.1.0 X-test-idtracker: no From: The IESG To: RFC Editor Cc: The IESG , , ietf-announce@ietf.org Date: Mon, 26 Feb 2007 23:19:44 -0500 X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Subject: Re: Experimental RFC to be: draft-nagami-mip6-nemo-multihome-fixed-network-03.txt Content-Length: 3088 Status: RO X-Lines: 82 The IESG has no problem with the publication of 'Multi-homing for small scale fixed network Using Mobile IP and NEMO' as an Experimental 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=11618&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 Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nagami-mip6-nemo-multihome-fixed-network-03.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 techniques either developed or under development in the MONAMI6 and NEMO working groups for solving a multihoming problem in a fixed network. Working Group Summary This is an independent submission via the RFC Editor. Protocol Quality Jari Arkko has reviwed the specification for conflicts with IETF work, as specified in RFC 3932. The NEMO, MONAMI6, SHIM6, and MIP6 chairs were contacted during this review. Note to RFC Editor The official response is The IESG thinks that this work is related to IETF work done in the MONAMI6, NEMO, MIP6, and SHIM6 working groups, but this does not prevent publishing. In addition we would like the RFC Editor and the authors to be careful in how they refer to ongoing work, to use the latest reference and to correctly characterize the state of the work. Specifically, draft-wakikawa-mobileip-multiplecoa reference should point to ongoing work in MONAMI6 WG, i.e., draft-ietf-monami6-multiplecoa, which is a later development of the same specification. The normative/informative reference status should be reviewed along with the text in the body of the document. The text should portray this work as an example of ongoing work unless the authors are willing to hold their work up for a normative reference. Similarly, draft-wakikawa-mip6-nemo-haha-01.txt has been discussed in the NEMO WG but has not yet been adopted, so it too should be characterized as an example of ongoing work. IESG Note Please use the standard IESG note 2: 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. IANA Note There are no IANA considerations. From rfc-ed@ISI.EDU Mon Feb 26 20:23:42 2007 X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SUBJ_HAS_SPACES,SUBJ_HAS_UNIQ_ID autolearn=no version=3.1.0 X-test-idtracker: no From: The IESG To: RFC Editor Cc: The IESG , , ietf-announce@ietf.org Date: Mon, 26 Feb 2007 23:22:09 -0500 X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Subject: Re: Informational RFC to be: draft-joslin-config-schema-17.txt Content-Length: 1591 Status: RO X-Lines: 47 The IESG has no problem with the publication of 'A Configuration Profile Schema for LDAP-based agents' 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=6357&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 Ted Hardie. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-joslin-config-schema-17.txt The process for such documents is described at http://www.rfc-editor.org/indsubs.html. Thank you, The IESG Secretary Technical Summary RFC Editor document being considered for conflict. Working Group Summary RFC Editor document being considered for conflict. Protocol Quality RFC Editor document being considered for conflict. 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. From ietf-announce-bounces@ietf.org Mon Feb 26 20:23:57 2007 X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 X-test-idtracker: no From: The IESG To: RFC Editor Date: Mon, 26 Feb 2007 23:22:09 -0500 X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: iana@iana.org, The IESG , ietf-announce@ietf.org List-Id: ietf-announce.ietf.org X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Subject: Re: Informational RFC to be: draft-joslin-config-schema-17.txt Content-Length: 1744 Status: RO X-Lines: 53 The IESG has no problem with the publication of 'A Configuration Profile Schema for LDAP-based agents' 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=6357&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 Ted Hardie. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-joslin-config-schema-17.txt The process for such documents is described at http://www.rfc-editor.org/indsubs.html. Thank you, The IESG Secretary Technical Summary RFC Editor document being considered for conflict. Working Group Summary RFC Editor document being considered for conflict. Protocol Quality RFC Editor document being considered for conflict. 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. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce From rfc-ed@ISI.EDU Thu Mar 1 12:30:03 2007 X-Spam-Status: No, score=-19.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_DEF_WHITELIST autolearn=ham version=3.1.0 Date: Thu, 1 Mar 2007 12:29:47 -0800 From: RFC Editor To: Bob Braden Subject: Change of Publication Path for draft-wing-behave-symmetric-rtprtcp User-Agent: Mutt/1.4.1i X-ISI-4-43-8-MailScanner: Found to be clean X-Lines: 36 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 905 ----- Forwarded message from IESG Secretary ----- To: RFC Editor Cc: iesg@ietf.org From: IESG Secretary Date: Mon, 12 Feb 2007 15:42:50 -0500 Subject: Change of Publication Path for draft-wing-behave-symmetric-rtprtcp To the RFC Editor; At the bi-weekly IESG Teleconference on February 8, 2007, the IESG discussed the independent submission to the RFC Editor document draft-wing-behave-symmetric-rtprtcp-01. After the group discussion, and individual contact with the author, the shepherding AD, Magnus Westerlund, has requested that the document change from an independent submission via the RFC Editor, to an AD sponsored document for Informational RFC status. Please make any necessary changes for this document to change publication paths. Thank you, The IESG Secretary ----- End forwarded message ----- From iesg-secretary@ietf.org Thu Mar 16 15:16:55 2007 From: The IESG To: RFC Editor Cc: The IESG , Date: Thu, 16 Mar 2006 15:16:55 -0500 Subject: Informational RFC to be: draft-white-pathconsiderations-05.txt Status: RO X-Lines: 52 Content-Type: text/plain; charset="us-ascii" Content-Length: 1391 The IESG has no problem with the publication of 'Considerations in Validating the Path in BGP' 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=11359&r fc_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 Alex Zinin. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-white-pathconsiderations-05.txt Thank you, The IESG Secretary Technical Summary This document reprents author's view on considerations related to BGP route path validation. Working Group Summary This document is an idvididual submission via RFC Editor. It has been referred to the RPSEC WG for a review. The WG has no objection to this document being published by the RFC Editor. Protocol Quality Not applicable. IESG Note: After consultation with the RPSEC WG, the IESG thinks that this work is related to IETF work done in WG RPSEC, but this does not prevent publishing. The IESG also recommends that a standard IESG note described in RFC 3932, section 4, case 2, is inserted in the document before publication. ----- End forwarded message ----- From rfc-ed@ISI.EDU Tue May 8 06:59:13 2007 X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SUBJ_HAS_SPACES,SUBJ_HAS_UNIQ_ID autolearn=no version=3.1.0 X-test-idtracker: no From: The IESG To: RFC Editor Cc: The IESG , , ietf-announce@ietf.org Date: Tue, 08 May 2007 09:58:03 -0400 X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Subject: Re: Informational RFC to be: draft-narasimhan-ietf-slapp-01.txt Content-Length: 6453 Status: RO X-Lines: 150 The IESG has no problem with the publication of 'SLAPP : Secure Light Access Point Protocol' 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=13058&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 Dan Romascanu. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-narasimhan-ietf-slapp-01.txt The process for such documents is described at http://www.rfc-editor.org/indsubs.html. Thank you, The IESG Secretary Technical Summary The CAPWAP problem statement (RFC 3990) describes a problem that needs to be addressed before a wireless LAN (WLAN) network designer can construct a solution composed of Wireless Termination Points (WTP) and Access Controllers (AC) from multiple, different vendors. One of the primary goals is to find a solution that solves the interoperability between the two classes of devices (WTPs and ACs) which then enables an AC from one vendor to control and manage a WTP from another. The interoperability problem is more general than as stated in the CAPWAP problem statement because it can arise out of other networks that do not necessarily involve WLAN or any wireless devices. A similar problem exists in any network that is composed of network elements that are managed by a centralized controller where these two classes of devices are from different vendors and need to interoperate with each other such that the network elements can be controlled and managed by the controller. A possible solution to this problem is to split it into two parts - one that is technology or application independent which serves as a common framework across multiple underlying technologies, and another that is dependent on the underlying technology that is being used in the network. For example, methods and parameters used by an 802.11 AC to configure and manage a network of 802.11 WTPs are expected to be quite different than that used by an equivalent 802.16 controller to manage a network of 802.16 base stations. The architectural choices for these two underlying technologies may also be significantly different. This document defines a protocol that forms the common technology-independent framework and the ability to negotiate and add, on top of this framework, a control protocol that contains a technology-dependent component to arrive at a complete solution. It also defines two such control protocols - an 802.11 Control protocol, and another a more generic image download protocol, in this draft. Even though the text in this document is written to specifically address the problem stated in RFC 3990, the solution can be applied to any problem that has a controller (equivalent to the AC) managing one or more network elements (equivalent to the WTP). Working Group Summary This document was a candidate protocol submission for the Control and Provisioning of Wireless Access Points (CAPWAP) Working Group. It is being published for informational and historical reference purposes. Protocol Quality The evaluation of the candidate protocols for CAPWAP is being described in RFC 4565. This document is not a candidate for any level of Internet Standard. The document has not had complete IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. Note to RFC Editor The IESG takes note that this submission is being published for historic reference, with the intention to document an initial submission for the CAPWAP protocol. In order to avoid confusion, the IESG recommends that this document be published only after the approval and publication of the CAPWAP protocol (draft-ietf-capwap- protocol-specification) as Proposed Standard. The IESG believes that the appropriate status at the publication of this RFC would be 'Historic', and that the note 'Obsoleted by RFC xxxx' should be added on the front page, where xxxx will be the RFC number of the CAPWAP protocol specification. RFC Editor, please make the following changes: 1. Place either in or immediately following the "Status of this Memo" section of the finished RFC the IESG note below 2. Add the note 'Obsoleted by RFC xxxx' on the front page, where xxxx will be the RFC number of the CAPWAP protocol specification. 3. Update the boilerplate according to RFC 4748 4. Rename 'References' Section as 'Informative References' 5. Replace outdated reference draft-ietf-capwap-objectives by RFC 4564 6. Replace outdated reference draft-rescorla-dtls by RFC 4347 7. Replace obsolete reference: RFC 2246 by RFC 4346 IESG Note In conformance with RFC 3932, Section 4, the IESG requests the publication of the following note: "This RFC documents the SLAPP protocol as it was when submitted to the IETF as a basis for further work in the CAPWAP WG, and therefore it may resemble the CAPWAP protocol specification (RFC XXXX), as well as other current IETF work in progress or published IETF work. This RFC is being published solely for the historical record. The protocol described in this RFC has not been thoroughly reviewed and may contain errors and omissions. RFC XXXX documents the standards track solution for the CAPWAP Working Group and obsoletes any and all mechanisms defined in this RFC. This RFC itself is not a candidate for any level of Internet Standard and should not be used as a basis for any sort of deployment in the Internet. The IETF disclaims any knowledge of the fitness of this RFC for any purpose, and in particular notes that it has not had complete 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." IANA Note As this document is not a candidate for standardization or deployment in the Internet, IANA is not required to take any action. From ietf-announce-bounces@ietf.org Tue May 8 07:47:57 2007 X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 X-test-idtracker: no From: The IESG To: RFC Editor Date: Tue, 08 May 2007 10:46:32 -0400 X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: iana@iana.org, The IESG , ietf-announce@ietf.org List-Id: ietf-announce.ietf.org X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Subject: Re: Informational RFC to be: draft-ohara-capwap-lwapp-04.txt Content-Length: 4549 Status: RO X-Lines: 112 The IESG has no problem with the publication of 'Light Weight Access Point Protocol' 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=11787&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 Dan Romascanu. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ohara-capwap-lwapp-04.txt The process for such documents is described at http://www.rfc-editor.org/indsubs.html. Thank you, The IESG Secretary Technical Summary The IETF's CAPWAP WG has identified that a standards based protocol is necessary between a wireless Access Controller and Wireless Termination Points (the latter are also commonly referred to as Light Weight Access Points). This specification defines the Light Weight Access Point Protocol (LWAPP), which addresses the CAPWAP's protocol requirements. Although the LWAPP protocol is designed to be flexible enough to be used for a variety of wireless technologies, this specific document describes the base protocol, and an extension that allows it to be used with the IEEE's 802.11 wireless LAN protocol. Working Group Summary This document was a candidate protocol submission for the Control and Provisioning of Wireless Access Points (CAPWAP) Working Group. It is being published for informational and historical reference purposes. Protocol Quality The evaluation of the candidate protocols for CAPWAP is being described in RFC 4565. This document is not a candidate for any level of Internet Standard. The document has not had complete IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. Note to RFC Editor The IESG takes note that this submission is being published for historic reference, with the intention to document an initial submission for the CAPWAP protocol. In order to avoid confusion, the IESG recommends that this document be published only after the approval and publication of the CAPWAP protocol (draft-ietf-capwap- protocol-specification) as Proposed Standard. The IESG believes that the appropriate status at the publication of this RFC would be 'Historic', and that the note 'Obsoleted by RFC xxxx' should be added on the front page, where xxxx will be the RFC number of the CAPWAP protocol specification. RFC Editor, please make the following changes: 1. Place either in or immediately following the "Status of this Memo" section of the finished RFC the IESG note below 2. Add the note 'Obsoleted by RFC xxxx' on the front page, where xxxx will be the RFC number of the CAPWAP protocol specification. 3. Replace obsolete normative reference: RFC 1750 by RFC 4086 IESG Note In conformance with RFC 3932, Section 4, the IESG requests the publication of the following note: "This RFC documents the LWAPP protocol as it was when submitted to the IETF as a basis for further work in the CAPWAP WG, and therefore it may resemble the CAPWAP protocol specification (RFC XXXX), as well as other current IETF work in progress or published IETF work. This RFC is being published solely for the historical record. The protocol described in this RFC has not been thoroughly reviewed and may contain errors and omissions. RFC XXXX documents the standards track solution for the CAPWAP Working Group and obsoletes any and all mechanisms defined in this RFC. This RFC itself is not a candidate for any level of Internet Standard and should not be used as a basis for any sort of deployment in the Internet. The IETF disclaims any knowledge of the fitness of this RFC for any purpose, and in particular notes that it has not had complete 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." IANA Note As this document is not a candidate for standardization or deployment in the Internet, IANA is not required to take any action. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce From ietf-announce-bounces@ietf.org Tue May 8 08:07:42 2007 X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 X-test-idtracker: no From: The IESG To: RFC Editor Date: Tue, 08 May 2007 11:05:46 -0400 X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: iana@iana.org, The IESG , ietf-announce@ietf.org List-Id: ietf-announce.ietf.org X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Subject: Re: Informational RFC to be: draft-iino-capwap-wicop-02.txt Content-Length: 4498 Status: RO X-Lines: 120 The IESG has no problem with the publication of 'Wireless LAN Control Protocol (WiCoP)' 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=13039&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 Dan Romascanu. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-iino-capwap-wicop-02.txt The process for such documents is described at http://www.rfc-editor.org/indsubs.html. Thank you, The IESG Secretary Technical Summary The Wireless LAN Control Protocol (WiCoP) described in this document allows for the control and provisioning of large-scale WLANs. It enables central management of these networks and realizes the objectives set forth for the control and provisioning of wireless access points (CAPWAP). Working Group Summary This document was a candidate protocol submission for the Control and Provisioning of Wireless Access Points (CAPWAP) Working Group. It is being published for informational and historical reference purposes. Protocol Quality The evaluation of the candidate protocols for CAPWAP is being described in RFC 4565. This document is not a candidate for any level of Internet Standard. The document has not had complete IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. Note to RFC Editor The IESG takes note that this submission is being published for historic reference, with the intention to document an initial submission for the CAPWAP protocol. In order to avoid confusion, the IESG recommends that this document be published only after the approval and publication of the CAPWAP protocol (draft-ietf-capwap- protocol-specification) as Proposed Standard. The IESG believes that the appropriate status at the publication of this RFC would be 'Historic', and that the note 'Obsoleted by RFC xxxx' should be added on the front page, where xxxx will be the RFC number of the CAPWAP protocol specification. RFC Editor, please make the following changes: 1. Place either in or immediately following the "Status of this Memo" section of the finished RFC the IESG note below 2. Add the note 'Obsoleted by RFC xxxx' on the front page, where xxxx will be the RFC number of the CAPWAP protocol specification. 3. Update the boilerplate according to RFC 4748 4. Rename 'References' Section as 'Informative References' 5. Replace outdated reference draft-ietf-capwap-arch by RFC 4118 6. Replace outdated reference draft-ietf-capwap-objectives by RFC 4564 7. Replace outdated reference draft-ietf-capwap-problem-statement by RFC 3990 IESG Note In conformance with RFC 3932, Section 4, the IESG requests the publication of the following note: "This RFC documents the WiCoP protocol as it was when submitted to the IETF as a basis for further work in the CAPWAP WG, and therefore it may resemble the CAPWAP protocol specification (RFC XXXX), as well as other current IETF work in progress or published IETF work. This RFC is being published solely for the historical record. The protocol described in this RFC has not been thoroughly reviewed and may contain errors and omissions. RFC XXXX documents the standards track solution for the CAPWAP Working Group and obsoletes any and all mechanisms defined in this RFC. This RFC itself is not a candidate for any level of Internet Standard and should not be used as a basis for any sort of deployment in the Internet. The IETF disclaims any knowledge of the fitness of this RFC for any purpose, and in particular notes that it has not had complete 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." IANA Note As this document is not a candidate for standardization or deployment in the Internet, IANA is not required to take any action. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce From ietf-announce-bounces@ietf.org Mon May 28 12:11:05 2007 X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 X-test-idtracker: no From: The IESG To: RFC Editor Date: Mon, 28 May 2007 15:09:34 -0400 X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: iana@iana.org, The IESG , ietf-announce@ietf.org List-Id: ietf-announce.ietf.org X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Subject: Re: Informational RFC to be: draft-friend-oftp2-04.txt Content-Length: 1602 Status: RO X-Lines: 45 The IESG has no problem with the publication of 'ODETTE File Transfer Protocol 2.0' 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=14627&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 Lisa Dusseault. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-friend-oftp2-04.txt The process for such documents is described at http://www.rfc-editor.org/indsubs.html. Thank you, The IESG Secretary Note to RFC Editor 1. The IESG has not found any conflict between this document and IETF work. 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. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce From rfc-ed@ISI.EDU Mon May 28 12:17:43 2007 X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SUBJ_HAS_SPACES,SUBJ_HAS_UNIQ_ID autolearn=no version=3.1.0 X-test-idtracker: no From: The IESG To: RFC Editor Cc: The IESG , Date: Mon, 28 May 2007 15:16:24 -0400 X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Subject: Re: Informational RFC to be: draft-carroll-dynmobileip-cdma-05.txt Content-Length: 1344 Status: RO X-Lines: 36 The IESG has no problem with the publication of 'Verizon Wireless Dynamic Mobile IP Key Update for cdma2000(R) Networks' 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=10350&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 Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-carroll-dynmobileip-cdma-05.txt The process for such documents is described at http://www.rfc-editor.org/indsubs.html. Thank you, The IESG Secretary This is an RFC Editor individual submission, and the IESG request that it be published with the following IESG note: "This document describes an existing deployed technology that was developed outside the IETF. It utilizes the RADIUS Access-Reject in order to provision service, which is incompatible with the RADIUS protocol, and practices the sharing of secret keys in public-key cryptosystems, which is not a practice the IETF recommends. The IESG recommends against using this protocol as a basis for solving similar problems in the future." From rfc-ed@ISI.EDU Fri Apr 11 06:24:25 2008 X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Content-Transfer-Encoding: 7bit From: Tim Polk Date: Fri, 11 Apr 2008 09:22:23 -0400 To: RFC Editor X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov Subject: updated RFC Editor Note for draft-ietf-kitten-gssapi-domain-based-names and draft-ietf-kitten-krb5-gssapi-domain-based-names X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-Lines: 52 Status: RO Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed" Content-Length: 1746 RFC Editor, I have updated the RFC Editor Note for the ballot set draft-ietf- kitten-gssapi-domain-based-names and draft-ietf-kitten-krb5-gssapi-domain-based-names to reflect the resolution of open issues with IANA. Since these documents are already in queue, I was concerned the updates might be missed. Accordingly, I am also providing the updated RFC Editor note here: ---- beginning of RFC Editor Note ----- Note to RFC Editor Please modify draft-ietf-kitten-gssapi-domain-based-names as follows: (1) Insert a new section 3.1 Name Type OID and renumber the current section 3.1 as 3.2. (2) Insert the following text as the body of the new section 3.1 The IANA should record the following new name-type OID in the IANA's "SMI Security for Name System Designators Codes (nametypes)" registry: 5 gss-domain-based-services [RFCxxxx] (3) In section 3.2, delete the following text: allocated manually with RFC2743 as the authoritative "registry" -- there is no IANA registry for GSS-API name types at this time. Therefore there are no IANA considerations in this document. (4) Please append a new closing paragraph at the end of Section 7 Security Considerations: Note that, as with all service names, the mere existence of a domain-based service name conveys meaningful information that may be used by initiators for making authorization decisions; therefore, administrators of distributed authentication services should be aware of the significance of the service names for which they create acceptor credentials." (5) Note: this RFC Editor note does not modify draft-ietf-kitten-krb5- gssapi-domain-based-names. ---- end of RFC Editor Note ----- Thanks, Tim Polk