Re: Last Call: draft-siemborski-rfc2554bis (SMTP Service Extension for Authentication) to Proposed Standard
Frank Ellermann wrote: Lisa Dusseault wrote: are we looking at the same version of this doc? No, the last called is -07, it doesn't REQUIRE [DIGEST-MD5] anymore: | Note that many existing client and server implementations implement | CRAM-MD5 [CRAM-MD5] SASL mechanism. In order to insure interoperability | with deployed software new implementations MAY implement it, however | implementations should be aware that this SASL mechanism doesn't | provide any server authentication. Implementations that want to provide | server authentication are encouraged to implement SASL mechanisms such | as DIGEST-MD5 [DIGEST-MD5]. The MAY is a bit obscure, of course they MAY do this, optionally. I'd prefer a clearer SHOULD to s/insure/ensure/ (?) interoperability. I didn't want to recommend it, but at the same time I wanted to let people know that CRAM-MD5 is deployed. If other people feel strongly about changing the MAY to the SHOULD, I will do the change. It has references to 2195 and 2831bis, and talks about SASLprep. How about using 2195bis, its security considerations might be more up to date ? The question of the 2195bis status (draft standard vs. informational) will be interesting, but it won't affect 2554bis, and maybe we'll find a compromise between those positions. I will be glad to reference 2195bis if it gets published soon enough. This change can be done during AUTH48. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: FW: Last Call: draft-heard-rfc4181-update (RFC 4181 Update to Recognize the IETF Trust) to BCP
C. M. Heard wrote: The draft is intended to do the same thing for RFC 4181 that RFC 4748 did for RFC 3978. Comments, if any, should be directed to ietf@ietf.org. Now that you ask, your patches are straight forward, so why not simply apply them and publish a complete new 4181bis ? Patchwork RFCs are IMO ugly. RFC 4748 was a special case, it was urgent, there was a competing 3978bis draft, and the IPR WG intends to update RFC 3978 anyway, soon. A somewhat radical proposal: If your patch is approved you could transform it into a complete 4181bis in AUTH48, and let that obsolete 4181. Or is the 4181 situation exacly as for 4748 + 3978 ? Your patch might be incomplete, chapter 3.7, appendix A, and the normative references mention 3978 instead of 3978 + 4748. Especially appendix A point 7 should now point to RFC 4748. IIRC RFC 3979 was also patched recently, but apparently it's still waiting for its RFC number, or I confuse some patches. It's tempting to use this trick, I considered a simple patch for an obscure detail in RFC 4409 8.1. But for readers (or for authors trying to get their references right) it's ugly. Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: FW: Last Call: draft-heard-rfc4181-update (RFC 4181 Update to Recognize the IETF Trust) to BCP
On Sat, 27 Jan 2007, Frank Ellermann wrote: C. M. Heard wrote: The draft is intended to do the same thing for RFC 4181 that RFC 4748 did for RFC 3978. Comments, if any, should be directed to ietf@ietf.org. Now that you ask, your patches are straight forward, so why not simply apply them and publish a complete new 4181bis ? Patchwork RFCs are IMO ugly. RFC 4748 was a special case, it was urgent, there was a competing 3978bis draft, and the IPR WG intends to update RFC 3978 anyway, soon. A somewhat radical proposal: If your patch is approved you could transform it into a complete 4181bis in AUTH48, and let that obsolete 4181. Or is the 4181 situation exacly as for 4748 + 3978 ? The situation for RFC 4181 is like this: new copyright language will be required in IETF MIB documents as of the beginning of next month, so we need to get an update out ASAP. The original plan was to issue a complete 4181bis, but the person who has volunteered to take over the editing duties is busy with other things, so I proposed the patch as an interim solution. (Note that we don't have xml source for this document, so the first job for the new editor is creating it ... not a trivial task.) My hope and expectation is that there will be a complete 4181bis in the not too distant future. Your patch might be incomplete, chapter 3.7, appendix A, and the normative references mention 3978 instead of 3978 + 4748. Especially appendix A point 7 should now point to RFC 4748. That's something that I hoped could wait for a complete 4181bis. //cmh ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF IP Contribution Policy
Larry Rosen, It is indicative of your letter's content that the introduction informs us that the IETF is the SDO responsible for Ethernet and WiFi (well, they both start with IE don't they?). Getting down to the letter itself. IETF, the most democratic and open of standards organizations, is proposing a contribution policy that, simply put, may result in standards that are not truly open for implementation and use in open source software. This draft formal policy ... expressly omits any patent licenses. Do you expect us to issue an RFC stating that anyone who submits an ID automatically grants a world-wide royalty-free license to use the described technology ? I doubt that this is a reasonable expectation. Many IETF participants do not have the authority to grant such license terms, and even were all authors to grant such licenses, I assume that you realize that their may be other parties holding IPR rights who have not participated. So I guess you furthermore expect anyone who submits an ID to indemnify eveyone with regards to third party IPR rights? These issues have been around for years, and the reasonable path, taken by the IETF, ITU and most other SDOs is to require participants to disclose their IPR, and to encourage them to disclose any IPR about which they know. Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
