Re: Publication track for IBE documents (Was Second Last Call...)
This thread has already pointed to the financial statements that show how much is paid for RFC Editor services. Russ At 08:56 PM 10/26/2008, TS Glassey wrote: There must be some financial models available from the proposal stage of the Editor Selection process, chair? Todd Glassey - Original Message - From: Stephane Bortzmeyer [EMAIL PROTECTED] To: Harald Alvestrand [EMAIL PROTECTED] Cc: ietf@ietf.org Sent: Thursday, October 23, 2008 2:24 AM Subject: Re: Publication track for IBE documents (Was Second Last Call...) On Wed, Oct 22, 2008 at 04:51:23PM +0200, Harald Alvestrand [EMAIL PROTECTED] wrote a message of 23 lines which said: (That said, the RFC Editor's work on these will cost the IETF a known amount of dollars. Known by who? How an ordinary IETF participant could find out The Real True Cost of a RFC? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.175 / Virus Database: 270.8.2/1741 - Release Date: 10/23/2008 7:54 AM ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Publication track for IBE documents (Was Second Last Call...)
On Wed, Oct 22, 2008 at 04:51:23PM +0200, Harald Alvestrand [EMAIL PROTECTED] wrote a message of 23 lines which said: (That said, the RFC Editor's work on these will cost the IETF a known amount of dollars. Known by who? How an ordinary IETF participant could find out The Real True Cost of a RFC? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Publication track for IBE documents (Was Second Last Call...)
Stephane Bortzmeyer wrote: On Wed, Oct 22, 2008 at 04:51:23PM +0200, Harald Alvestrand [EMAIL PROTECTED] wrote a message of 23 lines which said: (That said, the RFC Editor's work on these will cost the IETF a known amount of dollars. Known by who? How an ordinary IETF participant could find out The Real True Cost of a RFC? IETF homepage - IASA - Budget and Finance - Budget - 2008 Expenses: RFC Editor/Edit Svcs: 737.800 dollars. I don't have the RFCs per year number in my head just now. Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
The cost of a RFC (Was: Publication track for IBE documents (Was Second Last Call...)
On Thu, Oct 23, 2008 at 11:40:26AM +0200, Harald Alvestrand [EMAIL PROTECTED] wrote a message of 21 lines which said: IETF homepage - IASA - Budget and Finance - Budget - 2008 I prefer RFC 3986 :-) http://iaoc.ietf.org/documents/2008_Budget_Final.pdf Expenses: RFC Editor/Edit Svcs: 737.800 dollars. I don't have the RFCs per year number in my head just now. 321 RFC in 2007, so this is around 2,300 US dollars per RFC... Not including the editors and WG members' work, of course. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Publication track for IBE documents (Was Second Last Call...)
Stephen, I will concede that most of the excitement about IBE and other Weil Pairing based cryptography has been in the research community. However, the technology has matured and products are slowly emerging. (I am also loath to write off any technology that attempts to address our enrollment and credentialing problems, even though I see it as a simple re-ordering of the same process. That's a philosophical rathole, though.) Publication as Informational RFCs is worthwhile since these documents provide a basis for interoperability *if* adoption of IBE technology picks up steam. We already have multiple non-interoperable implementations of IBE- based email (Voltage and Trend Micro). These RFCs *won't* address the fundamental interoperability problem between Trend and Voltage, since Trend is using the Sakai-Kasahara algorithm and Voltage uses Boneh- Boeyen or Boneh-Franklin. However, if additional companies wish to join the IBE-based email market, these RFCs are a proactive step towards interoperability of future implementations. Thanks, Tim So while I don't strongly object to these as informational RFCs, I do wonder why, if only one implementation is ever likely, we need any RFC at all. Its not like these docs describe something one couldn't easily figure out were there a need, given that the (elegant but not especially useful) crypto has been around for a while without finding any serious applications. Stephen. Tim Polk wrote: Okay, I fat fingered this one. The S/MIME WG actually forwarded these documents with a recommendation that they be published as Informational. I intended to respect that consensus, but for one reason or another, they ended up in the Tracker marked for Standards track. It is clear that the WG got this one right, and I have changed the intended status on both documents to Informational. Thanks, Tim Polk ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Publication track for IBE documents (Was Second Last Call...)
Stephen Farrell wrote: So while I don't strongly object to these as informational RFCs, I do wonder why, if only one implementation is ever likely, we need any RFC at all. Its not like these docs describe something one couldn't easily figure out were there a need, given that the (elegant but not especially useful) crypto has been around for a while without finding any serious applications. My personal opinion is that Informational documents should have a low bar for publication. Thus, in the absence of compelling other information (such as a claim that the technology is incompetently described, or can't be implemented from the specs), I'd favour publication. (That said, the RFC Editor's work on these will cost the IETF a known amount of dollars. The bar shouldn't be TOO low.) Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Publication track for IBE documents (Was Second Last Call...)
On Oct 22, 2008, at 7:50 AM, Tim Polk wrote: Stephen, I will concede that most of the excitement about IBE and other Weil Pairing based cryptography has been in the research community. However, the technology has matured and products are slowly emerging. (I am also loath to write off any technology that attempts to address our enrollment and credentialing problems, even though I see it as a simple re-ordering of the same process. That's a philosophical rathole, though.) Publication as Informational RFCs is worthwhile since these documents provide a basis for interoperability *if* adoption of IBE technology picks up steam. We already have multiple non-interoperable implementations of IBE- based email (Voltage and Trend Micro) These RFCs *won't* address the fundamental interoperability problem between Trend and Voltage, since Trend is using the Sakai-Kasahara algorithm and Voltage uses Boneh-Boeyen or Boneh-Franklin. However, if additional companies wish to join the IBE-based email market, these RFCs are a proactive step towards interoperability of future implementations. One motivation for adopting the Identum technology was that encryption is based upon the sender's ID, where tokens combine with recipient's IDs provide a means for many recipients to decrypt a common message body. This approach solves a difficult problem when complying with HIPPA, GLBA, PCI DSS, UK Data Protection Act that want outbound messages managed. S/MIME encryption interferes with an ability to monitor one's outbound traffic, making compliance assurance difficult. It is my understanding all of these solutions are encumbered, but I am not a lawyer. -Doug Thanks, Tim So while I don't strongly object to these as informational RFCs, I do wonder why, if only one implementation is ever likely, we need any RFC at all. Its not like these docs describe something one couldn't easily figure out were there a need, given that the (elegant but not especially useful) crypto has been around for a while without finding any serious applications. Stephen. Tim Polk wrote: Okay, I fat fingered this one. The S/MIME WG actually forwarded these documents with a recommendation that they be published as Informational. I intended to respect that consensus, but for one reason or another, they ended up in the Tracker marked for Standards track. It is clear that the WG got this one right, and I have changed the intended status on both documents to Informational. Thanks, Tim Polk ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Publication track for IBE documents (Was Second Last Call...)
Okay, I fat fingered this one. The S/MIME WG actually forwarded these documents with a recommendation that they be published as Informational. I intended to respect that consensus, but for one reason or another, they ended up in the Tracker marked for Standards track. It is clear that the WG got this one right, and I have changed the intended status on both documents to Informational. Thanks, Tim Polk Harald wrote: SM wrote: At 05:37 20-10-2008, The IESG wrote: This is a second last call for consideration of the following document from the S/MIME Mail Security WG (smime): - 'Using the Boneh-Franklin and Boneh-Boyen identity-based Encryption Algorithms with the Cryptographic Message Syntax (CMS) ' draft-ietf-smime-bfibecms-10.txt as a Proposed Standard Technical issues raised in IETF Last Call and IESG evaluation have been resolved. However, there have been substantive changes in the relevant IPR disclosures statements since the review process was initiated. Specifically, IPR disclosure statement #888, (see https://datatracker.ietf.org/ipr/888/) was replaced by PR disclosure statement #950, (see https://datatracker.ietf.org/ipr/950/) This Last Call is intended to confirm continued community support in light of the new IPR disclosure statement. Given the limited scope of this Last Call, an abbreviated time period has been selected. Disclosure statement #888 mentions draft-martin-ibcs-08. That I-D was published as RFC 5091 in December 2007. Disclosure #950 submitted in May 2008 mentions new licensing terms for RFC 5091. That disclosure mentions that draft-ietf-smime-bfibecms-10 is on the Informational Track whereas it is on the Standards Track. As there seems to be only one implementation and very little public discussion about the draft, I don't see why it should be on the Standards Track. With licensing terms like these, I would want to see a compelling argument for why the community needs it standardized to put it on the standards track. Let it be informational. Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Publication track for IBE documents (Was Second Last Call...)
So while I don't strongly object to these as informational RFCs, I do wonder why, if only one implementation is ever likely, we need any RFC at all. Its not like these docs describe something one couldn't easily figure out were there a need, given that the (elegant but not especially useful) crypto has been around for a while without finding any serious applications. Stephen. Tim Polk wrote: Okay, I fat fingered this one. The S/MIME WG actually forwarded these documents with a recommendation that they be published as Informational. I intended to respect that consensus, but for one reason or another, they ended up in the Tracker marked for Standards track. It is clear that the WG got this one right, and I have changed the intended status on both documents to Informational. Thanks, Tim Polk Harald wrote: SM wrote: At 05:37 20-10-2008, The IESG wrote: This is a second last call for consideration of the following document from the S/MIME Mail Security WG (smime): - 'Using the Boneh-Franklin and Boneh-Boyen identity-based Encryption Algorithms with the Cryptographic Message Syntax (CMS) ' draft-ietf-smime-bfibecms-10.txt as a Proposed Standard Technical issues raised in IETF Last Call and IESG evaluation have been resolved. However, there have been substantive changes in the relevant IPR disclosures statements since the review process was initiated. Specifically, IPR disclosure statement #888, (see https://datatracker.ietf.org/ipr/888/) was replaced by PR disclosure statement #950, (see https://datatracker.ietf.org/ipr/950/) This Last Call is intended to confirm continued community support in light of the new IPR disclosure statement. Given the limited scope of this Last Call, an abbreviated time period has been selected. Disclosure statement #888 mentions draft-martin-ibcs-08. That I-D was published as RFC 5091 in December 2007. Disclosure #950 submitted in May 2008 mentions new licensing terms for RFC 5091. That disclosure mentions that draft-ietf-smime-bfibecms-10 is on the Informational Track whereas it is on the Standards Track. As there seems to be only one implementation and very little public discussion about the draft, I don't see why it should be on the Standards Track. With licensing terms like these, I would want to see a compelling argument for why the community needs it standardized to put it on the standards track. Let it be informational. Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
