Re: IETF Eurasia
On 2007-11-29, at 6:28, ext [EMAIL PROTECTED] wrote: I agree with your reasoning. I should have asked, why do *ALL* IETF meetings have to be monolithic and all-inclusive? They don't. Several WGs are holding interim meetings between the IETF meetings. I'm not sure if there have been joint interims with multiple WGs attending, but that could make sense if there's a difficult piece of work that they need to agree on. Our rules allow this. Lars ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
In any case, I would much rather have seen that published and later declared Historic than hold up all other RFCs. It isn't as if the IETF can control what actually gets implemented and deployed in any case - so why on earth does it *matter*? Whereas getting the vast majority of RFCs published promptly *does* matter. I agree. I don't think there should be any additional delay in RFC publication. It takes long enough as is. Unless we hold them up till any possible patent expires (e.g., 17+ years). Bob ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
On 2007-12-01 00:45, Harald Alvestrand wrote: Tom.Petch wrote: I recall a recent occasion when the IESG withdrew its approval, for draft-housley-tls-authz-extns a document that both before and after its approval generated a lot of heat, within and without a WG. Presumably the expedited process would, or at least could, have seen that published as an RFC. With that example in mind, a 60 day hold seems rather a good idea. In that case, it went into the RFC Editor queue on June 30,, 2006, and was yanked from the queue on February 26, 2007 - 8 months later. According to the third last call announcement: On June 27, 2006, the IESG approved Transport Layer Security (TLS) Authorization Extensions, (draft-housley-tls-authz-extns) as a proposed standard. On November 29, 2006, Redphone Security (with whom Mark Brown, a co-author of the draft is affiliated) filed IETF IPR disclosure 767. it was five months between approval and the IPR disclosure. A two-month hold wouldn't have caught it. (No idea why it was still hanging there long enough for the IPR disclosure to catch up with it...) In any case, I would much rather have seen that published and later declared Historic than hold up all other RFCs. It isn't as if the IETF can control what actually gets implemented and deployed in any case - so why on earth does it *matter*? Whereas getting the vast majority of RFCs published promptly *does* matter. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Westin Vancouver Update
At 10:55 PM -0800 11/28/07, Cullen Jennings wrote: Wow. That greatly exceeded my expectations for a resolution. Thanks to everyone who made that happen. +1. I'm impressed by both the substance of the resolution and the speed of it. Thanks to the secretariat staff for taking the brunt of the relocation burden. -- Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
Tom.Petch wrote: I recall a recent occasion when the IESG withdrew its approval, for draft-housley-tls-authz-extns a document that both before and after its approval generated a lot of heat, within and without a WG. Presumably the expedited process would, or at least could, have seen that published as an RFC. With that example in mind, a 60 day hold seems rather a good idea. In that case, it went into the RFC Editor queue on June 30,, 2006, and was yanked from the queue on February 26, 2007 - 8 months later. According to the third last call announcement: On June 27, 2006, the IESG approved Transport Layer Security (TLS) Authorization Extensions, (draft-housley-tls-authz-extns) as a proposed standard. On November 29, 2006, Redphone Security (with whom Mark Brown, a co-author of the draft is affiliated) filed IETF IPR disclosure 767. it was five months between approval and the IPR disclosure. A two-month hold wouldn't have caught it. (No idea why it was still hanging there long enough for the IPR disclosure to catch up with it...) Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
Original Message - From: Harald Alvestrand [EMAIL PROTECTED] To: ietf@ietf.org Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, November 29, 2007 7:52 AM Subject: Re: Should the RFC Editor publish an RFC in less than 2 months? IETF Chair skrev: Dear IETF Community: Due to a lot of hard work, the RFC Editor is publishing approved Internet-Drafts more quickly. Overall this is just what we want to happen. However, I am concerned that the RFC Editor is might be getting too quick. Anyone can appeal the approval of a document in the two months following the approval. In the past, there was not any danger of the RFC Editor publishing a document before this timer expired, and the only documents that became RFCs in less than 60 days were the ones where the IESG explicitly asked for expedited processing. The recent improvements by the RFC Editor make it likely that all documents will be moving through the publication process in less than two months. My short reply: Bad idea. In my opinion, placing such a hold on documents is a triumph of process over sanity. snip Such a hold is a dumb idea, and we shouldn't do it. Just publish, and if we turn out to have made the wrong decision, make a public statement saying that; one form of public statement is leaving a hole in the RFC Index. I recall a recent occasion when the IESG withdrew its approval, for draft-housley-tls-authz-extns a document that both before and after its approval generated a lot of heat, within and without a WG. Presumably the expedited process would, or at least could, have seen that published as an RFC. With that example in mind, a 60 day hold seems rather a good idea. Tom Petch Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-klensin-rfc2821bis (Simple Mail Transfer Protocol) to Draft Standard
-Original Message- From: The IESG [mailto:[EMAIL PROTECTED] Sent: Monday, November 26, 2007 8:33 PM To: IETF-Announce Subject: Last Call: draft-klensin-rfc2821bis (Simple Mail Transfer Protocol) to Draft Standard The IESG has received a request from an individual submitter to consider the following document: - 'Simple Mail Transfer Protocol ' draft-klensin-rfc2821bis-06.txt as a Draft Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-12-24. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-klensin-rfc2821bis-06.txt Implementation Report can be accessed at http://www.ietf.org/IESG/implementation.html I looked for the implementation report at the location described above and didn't see anything there with an obvious name. Where can the report be found? -Scott- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Eurasia
At 10:34 AM 11/30/2007, Lars Eggert wrote: I'm not sure if there have been joint interims with multiple WGs attending, but that could make sense if there's a difficult piece of work that they need to agree on Geopriv and Ecrit had a joint meeting a couple of years ago that was mostly attended by folks that do SIP and SIPPING too. It was a productive meeting. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RFC 5083 on Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type
A new Request for Comments is now available in online RFC libraries. RFC 5083 Title: Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type Author: R. Housley Status: Standards Track Date: November 2007 Mailbox:[EMAIL PROTECTED] Pages: 10 Characters: 22810 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-smime-cms-auth-enveloped-06.txt URL:http://www.rfc-editor.org/rfc/rfc5083.txt This document describes an additional content type for the Cryptographic Message Syntax (CMS). The authenticated-enveloped-data content type is intended for use with authenticated encryption modes. All of the various key management techniques that are supported in the CMS enveloped-data content type are also supported by the CMS authenticated-enveloped-data content type. [STANDARDS TRACK] This document is a product of the S/MIME Mail Security Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
