draft-dnsbl-harmful-01
Is there a proper place to discuss http://www.ietf.org/internet-drafts/draft-church-dnsbl-harmful-o1.txt ? There has been some discussion of the draft in the ASRG list, but no one their seems to be aware of the most appropriate venue for such discussion, nor does a visit to the IETF website. While the author does a good job of listing the negative aspects of domain name based blacklists, he omits the advantages. A balanced discussion would accept that for several reasons DNSBLs are the best available spam suppression technique. The first advantage of DNBLs I want to mention is a private benefit for the mail transfer operator, his users, and their corespondents. The typical mailserver using DNSBLs for spam suppression REJECTS suspected bad mail, while a typical content based scanner DISCARDS suspected spam, or leaves it in a spam folder. In the case of a false positive This is a significant advantage to the DNSBL, because the actual sender will get a notice of refusal from the DNSBL based system, but no notice at all of the discard from the content based system. A user or MTA operator might place much greater weight on lost mail than rejected mail, as lost mail may be the source of ill feeling, while rejected mail is merely an inconvenience. The second advantage I want to mention is the public benefit to all email users when MTA operators administer their sites to discourage the output of spam. In the present legal environment, the existence of DNSBLs is the primary motivation for such efforts. Without DNSBLs, many large ISPs and hosting companies would lose interest completely in suppressing spam spewage from their MTAs and IP addresses. With the resulting increase is spam messages, content analysis would become increasing difficult. Without consideration of the advantages of the DNSBL, the author has come to a foregone conclusion. An IETF document deprecating a superior solution is unfortunate. I am aware that some content based scanners are able to reject mail, and that some MTAs using DNSBLs discard mail, but both situations are unusual, and the former is technically difficult. In any case, placing suspected spam in a spam folder seems like more of a way to avoid legal liability than to improve the user experience. I am aware that some MTA operators are frustrated by their inability to get off certain DNSBLs, and I do not have a cost free solution. I have referred such operators in the past to my page at http://www.nber.org/sys-admin/smarthost.html which suggests that they obtain mail relay service from an operator of an unlisted MTA and provides some sources. I have done some original research on the effectiveness of DNSBLs which is posted at http://www.nber.org/sys-admin/dnsbl-comparison.html however, the quantitative results are less important here than the qualitative difference between rejected and lost mail, and the possibility that ISPs would no longer see any advantage to policing spam originating in there systems. Thank you for this opportunity to comment. Daniel Feenberg National Bureau of Economic Research 1050 Mass Ave Cambridge MA 02138 617-588-0343 feenberg at nber dotte org ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]
On Thursday, December 01, 2005 08:48:10 AM -0500 Bernie Volz (volz) [EMAIL PROTECTED] wrote: How about we address issue 1 by expanding the DHCID RR type code. We have 16-bits and we're just using 4 values presently. There's plenty of room for future expansion *SHOULD* someone come along and demand a new algorithm in the future. I can't see why this would EVER occur since this really isn't about strong cryptographic protection (we're just trying to make it non-trivial to find a client's identity by not storing it in clear text). I think that's a good start; in fact, I was going to propose something very similar. This solves half the problem; particularly, it makes it possible to indicate that some other hash is in use. It does bind the hash to the type, rather than allowing them to be specified orthogonally, but I don't think that's a major problem. If it ever becomes an issue, there should be no problem defining a type where the next 16 bits indicate a subtype and the 16 bits after that indicate a hash. However, it doesn't solve the other half of the problem, which is present even without considering changing hash algorithms. The problem is that for any given fqdn and DHCP client, there are multiple possible DHCID RR's; in particular, one for each type. In order the update mechanism to work without requiring either an advance query or multiple update attempts, all possible updaters must agree in advance on the type in use. This lack of negotiation seems problematic to me, even in the absence of multiple hash algorithms. -- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED] Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]
On Sunday, December 04, 2005 11:58:25 PM -0500 Bernie Volz (volz) [EMAIL PROTECTED] wrote: If you're going to have multiple DHCP servers, such as failover pairs, doing the DNS updates, you need to have those servers agree on how they will identify the clients. This is not JUST for DNS updates. Failover partners need to use the same identifiers for clients. The document I read identifies several possible situations in which DHCID records are used to coordinate between updaters which are not DHCP failover partners. It discusses a scenario in which multiple clients may attempt to issue updates for the same name (and, presumably, in which more than one client is authorized to issue such an update; otherwise, there would be no problem), and one in which a client moves between subnets served by different DHCP servers, both of which are authorized issue updates for the client's FQDN. You can plausibly argue that the two DHCP servers in the second scenario, while not failover partners, are nonetheless part of the same administrative domain and require coordination. Such an argument seems a little weak to me, but if that were the only issue, I could live with it. I suppose you can also argue that two clients configured to use the same name will (by design) not produce the same DHCID RR's even if they use the same type, and therefore there's not a problem if they use different types. That I'll definitely buy. However, what about a scenario where both a client and the DHCP server on its home network are authorized to do the updates. When the client is at home, it lets the server do the update. When it is off-site at an IETF meeting, the IETF DHCP server has no authorization to update the client's fqdn, so the client must do so itself. Now, if the client and its home DHCP server disagree on which type to use, then the update may fail. The rules are pretty clearly described in the RFC: For DHCPv4: 1. Use the DUID if the client identifier option is provided by the client and it is a DUID and the server supports it. This is a new RFC that is in the RFC-editor queue so no clients and servers yet support this. 2. Otherwise, use the client identifier option if provided by the client, 3. Otherwise, use htype and chaddr. The rules are clear, but require that all possible updaters have the same view of the world. Consider the client I described above, which identifies itself with a DUID. So, as far as the client knows, it should follow rule 1 and use the DUID to form a DHCID record. Unfortunately, the client's home DHCP server doesn't support DUID's, so it skips rule 1 and follows rule 2, using the client identifier. It gets worse when you start adding new types after DHCID support is widely deployed. In fact, you arguably have that problem already, since a client supporting this option doesn't know whether its home server even supports the DHCID RR, as opposed to using the TXT record method. If you think my example involving both a client and a server is contrived, consider a client which always does its own updates. When such a client is updated, it may begin supporting new DHCID record types. It may begin supporting DUID's, or even be required to switch from non-DUID client identifiers to DUID's because it now supports IPv6. In each of these cases, the client will fail to perform an update because its new DHCID value is different from the old one. You can require the client to give up its lease and remove the record prior to shutting down, but such a requirement is fragile because a client may shut down unexpectedly, with no chance to send a DDNS update first. In short, as long as the only authorized updaters are a set of carefully coordinated DHCP servers which never receive configuration changes or software upgrades, everything works. Once you introduce clients (which by their nature are unpredictable) or support for new DHCID types, the negotiation problem becomes an issue. It's possible to work around by performing an extra query to determine what DHCID type is in use, but you seem to want to avoid that. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]
If you're going to have multiple DHCP servers, such as failover pairs, doing the DNS updates, you need to have those servers agree on how they will identify the clients. This is not JUST for DNS updates. Failover partners need to use the same identifiers for clients. So, this is really not an issue. The rules are pretty clearly described in the RFC: For DHCPv4: 1. Use the DUID if the client identifier option is provided by the client and it is a DUID and the server supports it. This is a new RFC that is in the RFC-editor queue so no clients and servers yet support this. 2. Otherwise, use the client identifier option if provided by the client, 3. Otherwise, use htype and chaddr. For DHCPv6: 1. Use the DUID of the client. There really is no mystery here. - Bernie -Original Message- From: Jeffrey Hutzelman [mailto:[EMAIL PROTECTED] Sent: Sunday, December 04, 2005 11:43 PM To: Bernie Volz (volz); Sam Hartman; Mark Stapp (mjs) Cc: namedroppers@ops.ietf.org; ietf@ietf.org; Pekka Savola; Ted Lemon; iesg@ietf.org; dhcwg@ietf.org; Steven M. Bellovin; Jeffrey Hutzelman Subject: RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard] On Thursday, December 01, 2005 08:48:10 AM -0500 Bernie Volz (volz) [EMAIL PROTECTED] wrote: How about we address issue 1 by expanding the DHCID RR type code. We have 16-bits and we're just using 4 values presently. There's plenty of room for future expansion *SHOULD* someone come along and demand a new algorithm in the future. I can't see why this would EVER occur since this really isn't about strong cryptographic protection (we're just trying to make it non-trivial to find a client's identity by not storing it in clear text). I think that's a good start; in fact, I was going to propose something very similar. This solves half the problem; particularly, it makes it possible to indicate that some other hash is in use. It does bind the hash to the type, rather than allowing them to be specified orthogonally, but I don't think that's a major problem. If it ever becomes an issue, there should be no problem defining a type where the next 16 bits indicate a subtype and the 16 bits after that indicate a hash. However, it doesn't solve the other half of the problem, which is present even without considering changing hash algorithms. The problem is that for any given fqdn and DHCP client, there are multiple possible DHCID RR's; in particular, one for each type. In order the update mechanism to work without requiring either an advance query or multiple update attempts, all possible updaters must agree in advance on the type in use. This lack of negotiation seems problematic to me, even in the absence of multiple hash algorithms. -- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED] Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: EARLY submission deadline (Re: XML2RFC submission (was Re: ASCII art))
Doug Royer wrote: Brian E Carpenter wrote: Doug Royer wrote: ... It does no good to discuss text that almost everyone already knows has problems. ...it was created to ensure that everyone in the room is actually discussing the same thing. Yes. Perhaps something like SVN could be available. I can 'check in' versions and people could quickly diff them. I use http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht very frequently. This of course would make old versions of the draft available which I feel is useful when you do not remember why something is changed. I seem to recall that this list discussed if old draft versions should be removed or kept. Many times... I do not remember the results. There's never been a clear consensus on that, and it would in some interpretations be a formal change to the RFC 2026 standards process. But being a pragmatist, I also use http://tools.ietf.org/id/ very frequently. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: EARLY submission deadline - Fact or Fiction?
Stepping back a few days... Scott W Brim wrote: The reason we have the deadline is to protect the Secretariat from having to be heroes. However, best would be if the need for such protection didn't arise. Instead of assuming that things to be discussed in the meetings will be written just before the meeting, and creating complexity and bureaucracy around that assumption, institute a policy that nothing *will* be discussed in the meeting unless it has already been discussed on the mailing list and the WG has failed to reach agreement on the issue (note this is about issues, not documents). This is clearly an approach that any WG chair can take if they want, and it is almost the same as the general guideline we already have that meetings should be to discuss issues, not to hear talks. Sounds like input to draft-hoffman-taobis This will reduce the number of drafts which must get out just before the meeting to only those which capture the result of ongoing discussion. The others won't get discussed anyway. OK, I'm optimistic, I think you are, a little. but I see all this discussion of mechanisms to elaborate a situation we don't want to be in in the first place. And that the current deadlines were, in fact, put in place to avoid. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D file formats and internationalization
Hallam-Baker, Phillip wrote: The fact that Brian is English and lives in Zurich is irrelevant. As a matter of fact I don't live in Zürich; I live near Genève. Of course this matters. The problem is that it's not quite as straightforward as people think. I'm attempting to send this in UTF-8; I wonder how many people will receive it correctly? Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D file formats and internationalization
You may have sent it in UTF-8, but arrived here as ASCII : Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate3.uk.ibm.com id jB5E0WQg115170 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: quoted-printable Was that the intent ? Regards Marshall On Dec 5, 2005, at 9:00 AM, Brian E Carpenter wrote: Hallam-Baker, Phillip wrote: The fact that Brian is English and lives in Zurich is irrelevant. As a matter of fact I don't live in Zürich; I live near Genève. Of course this matters. The problem is that it's not quite as straightforward as people think. I'm attempting to send this in UTF-8; I wonder how many people will receive it correctly? Brian ___ 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
The IETF Trust License is too restricted
The text in section 9.5 appear to me to make it permanently impossible to incorporate portions of RFC in both free or proprietary products. I believe that is unacceptable, and that it is counter to the needs of many in the IETF community. In the IPR WG, I have documented that implementations of IETF documents distributed by Debian, FreeBSD and Sun need the rights to incorporate portions of RFCs in their products. The section reads: 9.5 Licenses The Trust (acting through the Trustees) shall have the right to grant licenses for the use of the Trust Assets on such terms, subject to Section 7.1, as the Trustees deem appropriate; provided, however, that the Trust shall not grant any license that would be deemed a transfer of ownership or abandonment of any Trust Assets under applicable law. Specifically, any license granted by the Trust for the use of the Trust Assets consisting of IPR shall include provisions stating that (a) the licensee agrees to grant and assign to the Trust all right, title, and interest it may have -- or claim in any derivative works of Licensee that are based on or - incorporate the IPR, and (b) the licensee’s use of the IPR and any --- goodwill associated therewith shall inure to the benefit of the Trust. I believe the requirement to give up all rights to derivative works of the IETF IPR would be unacceptable to the Debian and FreeBSD community. They are not in a legal position to grant the Trust all rights to derivative works of the work that include portions of RFCs. I assume companies like Sun would find it difficult to grant the IETF Trust all rights to the Solaris operating system, which include excerpts from RFCs. If the IETF, in RFC 3978bis, gave third parties the right to use, modify and distribute RFCs, this would not be a problem. But RFC 3978 nor the current RFC 3978bis proposal does not grant those rights. The only mechanism to be able to grant those rights to the Debian and the FreeBSD community in the future will be to release those works via the IETF Trust. As described above, the IETF Trust cannot grant a sub-license without the requiring the above. I believe that requirement is unacceptable to most members in the IETF community. To fix this problem, remove the sentences that begin with Specifically, thus making the section read: The Trust (acting through the Trustees) shall have the right to grant licenses for the use of the Trust Assets on such terms, subject to Section 7.1, as the Trustees deem appropriate; provided, however, that the Trust shall not grant any license that would be deemed a transfer of ownership or abandonment of any Trust Assets under applicable law. I believe the issues raised under Specifically do not follow from the first part of the paragraph. They seriously limits the IETF Trusts capabilities to grant sub-licenses, and should be removed. The IETF Trust should be able to grant unrestricted sub-licenses. Finally, less than 4 weeks of time to review a long complicated legal document is insufficient. My lawyer is on vacation until after Christmas. Lawyers from organizations such as the Free Software Foundation (FSF) and the Electronic Frontier Foundation (EFF) cannot be expected to respond this fast. This document is given less review time than even some technical documents. Given the importance of this work, I believe one year of review would be more appropriate, if you wanted to guarantee the widest possible review of relevant and competent people. It takes time to get useful output from lawyers. (The less than 4 weeks is based on the first announcement posted on November 11, and the now extended deadline of December 8th.) Thanks, Simon Brian Carpenter [EMAIL PROTECTED] writes: (posted for Lucy Lynch, IAOC Chair) All - The amended language for Section 9.5 (Licensing) of the IETF Trust was posted to the IETF lists on December 1st and the IETF Trust FAQ has been updated to reflect the new text (see below). We have also added additional details on the handling of historical data. As we develop procedures for the transfer of assets into the IETF Trust and an inventory of items held by the IETF Trust we will publish them to the IAOC web site (see: http://koi.uoregon.edu/~iaoc/) Several people asked for additional time to review our final language, and with that in mind, I would like to extend this Call one last time to December 8th, 2005. Please send comments to: ietf@ietf.org or iaoc.ietf.org - Thanks Lucy E. Lynch Academic User Services Computing CenterUniversity of Oregon llynch @darkwing.uoregon.edu (541) 346-1774 FAQ Updates:
RE: The IETF Trust License is too restricted
Behalf Of Simon Josefsson The text in section 9.5 appear to me to make it permanently impossible to incorporate portions of RFC in both free or proprietary products. I believe the requirement to give up all rights to derivative works of the IETF IPR would be unacceptable to the Debian and FreeBSD community. They are not in a legal position to grant the Trust all rights to derivative works of the work that include portions of RFCs. That raises a question that I have not seen answered yet. What is the purpose of the trust if not to attempt to prevent unauthorized derrivative works? Today it is possible to make a proposal to IETF process, have that WG implode (e.g. MARID) and then take the specification to an alternative forum. This might appear to some to be a good idea. In practice however the parties that might do such a thing are the parties that begin a standards process by asking the question 'what forum should we choose?'. It would be a very bad idea for the IETF to attempt to make that choice irrevocable. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The IETF Trust License is too restricted
Brian E Carpenter [EMAIL PROTECTED] writes: Simon, You are bit behind real time. We already updated this text. http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg01837.html Thanks! This was also pointed out in private e-mail. The new text do solve my concern. I do think it is somewhat confusing, though. The second half starts with Specifically, but the qualifications and restrictions in the second half does not follow from, or even seem related to, the qualifications in the first half. My concern with the short review period remains though. Thanks, Simon Brian Simon Josefsson wrote: The text in section 9.5 appear to me to make it permanently impossible to incorporate portions of RFC in both free or proprietary products. I believe that is unacceptable, and that it is counter to the needs of many in the IETF community. In the IPR WG, I have documented that implementations of IETF documents distributed by Debian, FreeBSD and Sun need the rights to incorporate portions of RFCs in their products. The section reads: 9.5 Licenses The Trust (acting through the Trustees) shall have the right to grant licenses for the use of the Trust Assets on such terms, subject to Section 7.1, as the Trustees deem appropriate; provided, however, that the Trust shall not grant any license that would be deemed a transfer of ownership or abandonment of any Trust Assets under applicable law. Specifically, any license granted by the Trust for the use of the Trust Assets consisting of IPR shall include provisions stating that (a) the licensee agrees to grant and assign to the Trust all right, title, and interest it may have -- or claim in any derivative works of Licensee that are based on or - incorporate the IPR, and (b) the licensee’s use of the IPR and any --- goodwill associated therewith shall inure to the benefit of the Trust. I believe the requirement to give up all rights to derivative works of the IETF IPR would be unacceptable to the Debian and FreeBSD community. They are not in a legal position to grant the Trust all rights to derivative works of the work that include portions of RFCs. I assume companies like Sun would find it difficult to grant the IETF Trust all rights to the Solaris operating system, which include excerpts from RFCs. If the IETF, in RFC 3978bis, gave third parties the right to use, modify and distribute RFCs, this would not be a problem. But RFC 3978 nor the current RFC 3978bis proposal does not grant those rights. The only mechanism to be able to grant those rights to the Debian and the FreeBSD community in the future will be to release those works via the IETF Trust. As described above, the IETF Trust cannot grant a sub-license without the requiring the above. I believe that requirement is unacceptable to most members in the IETF community. To fix this problem, remove the sentences that begin with Specifically, thus making the section read: The Trust (acting through the Trustees) shall have the right to grant licenses for the use of the Trust Assets on such terms, subject to Section 7.1, as the Trustees deem appropriate; provided, however, that the Trust shall not grant any license that would be deemed a transfer of ownership or abandonment of any Trust Assets under applicable law. I believe the issues raised under Specifically do not follow from the first part of the paragraph. They seriously limits the IETF Trusts capabilities to grant sub-licenses, and should be removed. The IETF Trust should be able to grant unrestricted sub-licenses. Finally, less than 4 weeks of time to review a long complicated legal document is insufficient. My lawyer is on vacation until after Christmas. Lawyers from organizations such as the Free Software Foundation (FSF) and the Electronic Frontier Foundation (EFF) cannot be expected to respond this fast. This document is given less review time than even some technical documents. Given the importance of this work, I believe one year of review would be more appropriate, if you wanted to guarantee the widest possible review of relevant and competent people. It takes time to get useful output from lawyers. (The less than 4 weeks is based on the first announcement posted on November 11, and the now extended deadline of December 8th.) Thanks, Simon Brian Carpenter [EMAIL PROTECTED] writes: (posted for Lucy Lynch, IAOC Chair) All - The amended language for Section 9.5 (Licensing) of the IETF Trust was posted to the IETF lists on December 1st and the IETF Trust FAQ has been updated to reflect the new text (see below). We have also added additional details on the handling of historical
Re: The IETF Trust License is too restricted
Simon, You are bit behind real time. We already updated this text. http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg01837.html Brian Simon Josefsson wrote: The text in section 9.5 appear to me to make it permanently impossible to incorporate portions of RFC in both free or proprietary products. I believe that is unacceptable, and that it is counter to the needs of many in the IETF community. In the IPR WG, I have documented that implementations of IETF documents distributed by Debian, FreeBSD and Sun need the rights to incorporate portions of RFCs in their products. The section reads: 9.5 Licenses The Trust (acting through the Trustees) shall have the right to grant licenses for the use of the Trust Assets on such terms, subject to Section 7.1, as the Trustees deem appropriate; provided, however, that the Trust shall not grant any license that would be deemed a transfer of ownership or abandonment of any Trust Assets under applicable law. Specifically, any license granted by the Trust for the use of the Trust Assets consisting of IPR shall include provisions stating that (a) the licensee agrees to grant and assign to the Trust all right, title, and interest it may have -- or claim in any derivative works of Licensee that are based on or - incorporate the IPR, and (b) the licensee’s use of the IPR and any --- goodwill associated therewith shall inure to the benefit of the Trust. I believe the requirement to give up all rights to derivative works of the IETF IPR would be unacceptable to the Debian and FreeBSD community. They are not in a legal position to grant the Trust all rights to derivative works of the work that include portions of RFCs. I assume companies like Sun would find it difficult to grant the IETF Trust all rights to the Solaris operating system, which include excerpts from RFCs. If the IETF, in RFC 3978bis, gave third parties the right to use, modify and distribute RFCs, this would not be a problem. But RFC 3978 nor the current RFC 3978bis proposal does not grant those rights. The only mechanism to be able to grant those rights to the Debian and the FreeBSD community in the future will be to release those works via the IETF Trust. As described above, the IETF Trust cannot grant a sub-license without the requiring the above. I believe that requirement is unacceptable to most members in the IETF community. To fix this problem, remove the sentences that begin with Specifically, thus making the section read: The Trust (acting through the Trustees) shall have the right to grant licenses for the use of the Trust Assets on such terms, subject to Section 7.1, as the Trustees deem appropriate; provided, however, that the Trust shall not grant any license that would be deemed a transfer of ownership or abandonment of any Trust Assets under applicable law. I believe the issues raised under Specifically do not follow from the first part of the paragraph. They seriously limits the IETF Trusts capabilities to grant sub-licenses, and should be removed. The IETF Trust should be able to grant unrestricted sub-licenses. Finally, less than 4 weeks of time to review a long complicated legal document is insufficient. My lawyer is on vacation until after Christmas. Lawyers from organizations such as the Free Software Foundation (FSF) and the Electronic Frontier Foundation (EFF) cannot be expected to respond this fast. This document is given less review time than even some technical documents. Given the importance of this work, I believe one year of review would be more appropriate, if you wanted to guarantee the widest possible review of relevant and competent people. It takes time to get useful output from lawyers. (The less than 4 weeks is based on the first announcement posted on November 11, and the now extended deadline of December 8th.) Thanks, Simon Brian Carpenter [EMAIL PROTECTED] writes: (posted for Lucy Lynch, IAOC Chair) All - The amended language for Section 9.5 (Licensing) of the IETF Trust was posted to the IETF lists on December 1st and the IETF Trust FAQ has been updated to reflect the new text (see below). We have also added additional details on the handling of historical data. As we develop procedures for the transfer of assets into the IETF Trust and an inventory of items held by the IETF Trust we will publish them to the IAOC web site (see: http://koi.uoregon.edu/~iaoc/) Several people asked for additional time to review our final language, and with that in mind, I would like to extend this Call one last time to December 8th, 2005. Please send comments to: ietf@ietf.org or iaoc.ietf.org - Thanks Lucy E. Lynch Academic User Services
Re: I-D file formats and internationalization
Marshall Eubanks wrote: You may have sent it in UTF-8, but arrived here as ASCII : Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate3.uk.ibm.com id jB5E0WQg115170 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: quoted-printable Was that the intent ? It wasn't *my* intent :-) But in fact, that's the transfer encoding that got converted. My outgoing transfer encoding was Content-Transfer-Encoding: 8bit The content type was still tagged as UTF-8. OTOH your response is tagged Content-Type: text/plain; charset=ISO-8859-1 and indeed did get converted somewhere, at your end I suspect. It's not so easy to assert that UTF-8 just works. Brian Regards Marshall On Dec 5, 2005, at 9:00 AM, Brian E Carpenter wrote: Hallam-Baker, Phillip wrote: The fact that Brian is English and lives in Zurich is irrelevant. As a matter of fact I don't live in Zürich; I live near Genève. Of course this matters. The problem is that it's not quite as straightforward as people think. I'm attempting to send this in UTF-8; I wonder how many people will receive it correctly? Brian ___ 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: draft-dnsbl-harmful-01
--On 4. desember 2005 10:26 -0500 Daniel Feenberg [EMAIL PROTECTED] wrote: Is there a proper place to discuss http://www.ietf.org/internet-drafts/draft-church-dnsbl-harmful-o1.txt ? There has been some discussion of the draft in the ASRG list, but no one their seems to be aware of the most appropriate venue for such discussion, nor does a visit to the IETF website. This is an individual draft, so the most proper procedure is to ask the author what forum he wishes to have it discussed in. Personally, I think the ASRG mailing list is a reasonable venue to pick. Harald Alvestrand pgp96gcB4r5aD.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-dnsbl-harmful-01
On Mon, 5 Dec 2005, Harald Tveit Alvestrand wrote: --On 4. desember 2005 10:26 -0500 Daniel Feenberg [EMAIL PROTECTED] wrote: Is there a proper place to discuss http://www.ietf.org/internet-drafts/draft-church-dnsbl-harmful-o1.txt ? There has been some discussion of the draft in the ASRG list, but no one their seems to be aware of the most appropriate venue for such discussion, nor does a visit to the IETF website. This is an individual draft, so the most proper procedure is to ask the author what forum he wishes to have it discussed in. Personally, I think the ASRG mailing list is a reasonable venue to pick. The author of that draft already sent it to rfc-editor for publication (and he never before asked for comments or presented the draft on any anti-spam mail list as far as I know). Discussion on the draft would certainly be helpful, especially in light of existence of dnsbl draft that was worked on asrg for several years and now being prepared for submission as well. -- William Leibzon Elan Networks [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The IETF Trust License is too restricted
Hallam-Baker, Phillip wrote: ... What is the purpose of the trust if not to attempt to prevent unauthorized derrivative works? Its purpose is to give the IETF control of its own IPR, which has previously been held by 3rd parties. (That's not the legal statement of purpose in the formal Trust Agreement.) What we then do once we have such control is then something we can discuss and reach consensus on. Part of that discussion is already happening in the IPR WG. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D file formats and internationalization
One interesting thing is that the umlaut on the U in Zurich and the accent grave in Geneva came though, and came back as well (on the response to my response). They look fine, and are coded as Zürich; Genève So, if your use of UTF-8 was intended to display that, I think that (for me, OS X 10.4.3) the software did the right thing. Marshall On Dec 5, 2005, at 10:03 AM, Brian E Carpenter wrote: Marshall Eubanks wrote: You may have sent it in UTF-8, but arrived here as ASCII : Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate3.uk.ibm.com id jB5E0WQg115170 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: quoted-printable Was that the intent ? It wasn't *my* intent :-) But in fact, that's the transfer encoding that got converted. My outgoing transfer encoding was Content-Transfer-Encoding: 8bit The content type was still tagged as UTF-8. OTOH your response is tagged Content-Type: text/plain; charset=ISO-8859-1 and indeed did get converted somewhere, at your end I suspect. It's not so easy to assert that UTF-8 just works. Brian Regards Marshall On Dec 5, 2005, at 9:00 AM, Brian E Carpenter wrote: Hallam-Baker, Phillip wrote: The fact that Brian is English and lives in Zurich is irrelevant. As a matter of fact I don't live in Zürich; I live near Genève. Of course this matters. The problem is that it's not quite as straightforward as people think. I'm attempting to send this in UTF-8; I wonder how many people will receive it correctly? Brian ___ 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: I-D file formats and internationalization
Ted, -- -- The IETF does not make any effort to be representative of the Internet -- community. -- -- 1) They do too. -- -- Hmmm. I would have thought proof by assertion would be more fun. -- -- Seriously, you can argue that the IETF is failing to reach the -- stakeholders it claims to represent, but I think it's disingenuous to say -- that the group doesn't try to reach them. There are low barriers to -- entry for interested parties, and concentrated efforts to find and -- coordinate with other networking standards bodies. Those aren't the -- actions of a group of ostriches. It is true that the barriers to entry are low. But, then, ostriches were not born with their heads in the sand. How is the IETF process of driving new people away because they say stuff nobody wants to hear, different from burying its head in the sand? -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Ted Faber -- Sent: Friday, December 02, 2005 11:25 PM -- To: Hallam-Baker, Phillip -- Cc: ietf@ietf.org -- Subject: Re: I-D file formats and internationalization -- -- ___ -- 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: The IETF Trust License is too restricted
From: Brian E Carpenter [mailto:[EMAIL PROTECTED] Its purpose is to give the IETF control of its own IPR, which has previously been held by 3rd parties. (That's not the legal statement of purpose in the formal Trust Agreement.) What we then do once we have such control is then something we can discuss and reach consensus on. Part of that discussion is already happening in the IPR WG. That is an interesting approach. The reason I raised the point was that I suspect that there will be many members of the IETF community who would prefer to have the debate on use before they have surrendered control. The IETF constitution is not one that lends itself well to the 'trust me' approach. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
I know I am dumb stupid but I am also dumb stubborn [was IETF Trust license is too restricted]
At 15:50 05/12/2005, Brian E Carpenter wrote: Simon, You are bit behind real time. We already updated this text. http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg01837.html Dear Brian, Great! the three stupid points I am stubbornly interested in are gathered here! Please read what follows with humour, however the three issues are serious. 1. could someone be kind enough to tell me which RFC forbids to quote the URL of the currently discussed Drafts, as everyone and netiquette demand it for every other quote. Even before the supposed mines, this is probably the most consuming DoS in the IETF debate. And does not help outreach and welcome. No offence intended, but I really think this is (with correct name spelling) a point for a practical change. 2. I never saw anyone granted rights without corresponding duties. I beg in vain from you and the IAOC who is legally responsible if an RFC is judged a legal offense? Who is to pay the fine? Who will go to jail? Only this will tell who really owns the IETF IPRs. I know the RFC 3066 bis rises this issue: is it why no one wants to answer? or is http://www.theregister.co.uk/2005/12/05/minc_icann_letter/ too near an issue to risk addressing anything associated with the issue? Why my last IESG appeal with its consequences is not addressed? 3. I have real difficulty understanding why an Internet user/developer needs to beg an IETF license to use, quote, change, work on an RFC? And what will happen if he does not? I saw no difference between the Global Internet Community and the IETF Community until RFC 3935 told me the later was to influence the former (through legal IPR actions to force orthodoxy?). Until then I was stupid enough to believe the IETF IPRs were to protect their open use and the free debate of every Internet user and developer. Licensing permissions seem totally foreign to an open use? Unless it is a general permanent and total open use license to everyone? Does someone want to get royalties on TCP/IP (as de facto on the DNS and on IP addressing)? Or is there a political control because the USG financed the Internet? If I copy all the RFCs, sort their content, add a legal blabla paying my respects to all those who contributed through the IETF, make an open use e-book from them all, class their proposition in some orders, updating it when they change, mixing them with other SSDOs propositions, etc. translating parts in various languages, adding comments on their usage cons and pros and testing, linking the various comments people may have made on them, etc. quoting available open source/commercial libraries and their variations, etc. and the various registry repositories where they can find the values of the related parameters, i.e. what the users long for a while, will the IAOC sue me and send me to jail as the US DMCA and the French DADVSI would do? thank you jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The IETF Trust License is too restricted
In your previous mail you wrote: The text in section 9.5 appear to me to make it permanently impossible to incorporate portions of RFC in both free or proprietary products. I believe that is unacceptable, and that it is counter to the needs of many in the IETF community. = I support Simon's concern: as I explained we need to be allowed to freely quote RFCs, for instance in a comment in a piece of open source code. Regards [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Final Update - IETF Trust Consensus Call
(posted for Lucy Lynch, IAOC Chair) All - The amended language for Section 9.5 (Licensing) of the IETF Trust was posted to the IETF lists on December 1st and the IETF Trust FAQ has been updated to reflect the new text (see below). We have also added additional details on the handling of historical data. As we develop procedures for the transfer of assets into the IETF Trust and an inventory of items held by the IETF Trust we will publish them to the IAOC web site (see: http://koi.uoregon.edu/~iaoc/) Several people asked for additional time to review our final language, and with that in mind, I would like to extend this Call one last time to December 8th, 2005. Please send comments to: ietf@ietf.org or iaoc.ietf.org - Thanks Lucy E. Lynch Academic User Services Computing CenterUniversity of Oregon llynch @darkwing.uoregon.edu (541) 346-1774 FAQ Updates: - 18. How will the license provisions in Section 9.5 affect the contents of Standards related documents like RFCs and Internet Drafts. The IETF IPR rules in force when such documents were published still apply and Section 9.5 has been updated to reflect community concerns about the effect of licensing terms. The new text reads: 9.5 Licenses. The Trust (acting through the Trustees) shall have the right to grant licenses for the use of the Trust Assets on such terms, subject to Section 7.1, as the Trustees deem appropriate; provided, however, that the Trust shall not grant any license that would be deemed a transfer of ownership or abandonment of any Trust Assets under applicable law. Specifically, any license granted by the Trust for the use of the Trust Assets consisting of IPR other than rights in IETF standards-related documents (such as RFCs, Internet Drafts and the like) that have been acquired by the Trust through non-exclusive licenses granted by their contributors pursuant to the IETF community-approved procedures currently set forth in RFC 3978, and any community-approved updates and revisions thereto, shall include provisions stating that (a) the licensee agrees to grant and assign to the Trust all right, title, and interest it may have or claim in any derivative works of licensee that are based on or incorporate the IPR, and (b) the licensee's use of the IPR and any goodwill associated therewith shall inure to the benefit of the Trust. 19. Which of the assets listed in Schedule A will be transferred when the IETF Trust is established? Will the Trustees publish an accounting of these assets? All of the Marks, Domain Names, and Current Data listed in Schedule A will be transferred at closing. In addition, Historical Data that is currently available from available from the servers currently operated by or for the IETF Secretariat (i.e. data available on spinning disk) will also be transferred at closing. The Trustees will inventory all assets and provide a full accounting to the IETF community. Historical data which is currently in-accessible will be subject to the conditions outlined in sub-sections b-g. When and if additional data becomes available, those assets will transfer to the IETF Trust and will be added to the inventory. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'An ENUM Registry Type for the Internet Registry Information Service' to Proposed Standard
The IESG has approved the following document: - 'An ENUM Registry Type for the Internet Registry Information Service ' draft-ietf-enum-iris-ereg-02.txt as a Proposed Standard This document is the product of the Telephone Number Mapping Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-iris-ereg-02.txt-02.txt Technical Summary This document describes an IRIS (RFCs 3981-3983) registry schema for registered ENUM information The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by ENUM registries. The document includes support for privacy labeling of objects in the registries. Working Group Summary The working group gave a detailed consensus to this document, after many cycles of discussion and review. Protocol Quality Allison Mankin reviewed the specification for the IESG and notes that the specification should be reviewed to see if new enumservices such as the local number portability data will need extensions from it in future. Elwyn Davies gave a useful review for the General Area Directorate. Notes to RFC Editor: 1. Delete the following from Section 3.2.5, and delete reference [15] o IDNeMail - elements containing an e-mail address within an internationalized domain name [15]. 2. Section 8.2 OLD: S-NAPTR application service label NEW: S-NAPTR application service tag [20] [20] is a normative reference to RFC 3958 3. Section 3.24 OLD: o hostName - the fully qualified domain name of the host. The contents of this element are a domain name and MUST conform to RFC 1035 [9]. NEW: o hostName - the fully qualified domain name of the host. The contents of this element are a host name and MUST conform to RFC 1123 [xx]. Add a normative Reference to RFC 1123. 4. Section 3.4 OLD: o enum - the fully qualified name of an ENUM domain. This is a domain name as specified by RFC 1035 [9]. It yields a enum (Section 3.2.3) in the response. NEW: o enum - the fully qualified name of an ENUM domain. This is a domain name as specified by RFC 3761 [18]. It yields a enum (Section 3.2.3) in the response. 5. Normative References: Replace [3] and [4] with [3] World Wide Web Consortium, XML Schema Part 2: Datatypes, W3C XML Schema, October 2004, http://www.w3.org/TR/xmlschema-2/. [4] World Wide Web Consortium, XML Schema Part 1: Structures, W3C XML Schema, October 2004, http://www.w3.org/TR/xmlschema-1/ 6. Section 3.2.3 OLD: e164Number+1 7035 555 1212/e164Number NEW: e164Number+1 703 555 1212/e164Number There are four occurrences of the number 555 1212 in this section. Please replace 1212 with 1234. (1212 is a working number, whereas 1234 is a valid example). ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Transmission of IPv6, IPv4 and ARP Packets over Fibre Channel' to Proposed Standard
The IESG has approved the following document: - 'Transmission of IPv6, IPv4 and ARP Packets over Fibre Channel ' draft-ietf-imss-ip-over-fibre-channel-03.txt as a Proposed Standard This document obsoletes RFC2625 and RFC3831. This document is the product of the Internet and Management Support for Storage Working Group. The IESG contact persons are Bert Wijnen and David Kessens. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imss-ip-over-fibre-channel-03.txt Technical Summary This document specifies the encapsulation of IPv6, IPv4 and ARP packets over Fibre Channel. This document also specifies the methods for forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on Fibre Channel networks, and a mechanism to perform IPv4 address resolution over Fibre Channel networks. This document (when published as RFC) obsoletes RFC2625 and RFC3831. Working Group Summary This document has been reviewed by Fibre Channel experts in Technical Committee T11 (Fibre Channel standards organization) in addition to members of the IMSS WG. There is solid support for this document both in the WG and from T11. Protocol Quality This document replaces and consolidates two separate RFCs on IPv4 over Fibre Channel (RFC 2625) and IPv6 over Fibre Channel (RFC 3831). Most of its technical content is unchanged from those RFCs. The technical changes that have been made are primarily based on implementation experience. The protocol has been reviewed for the IESG by David L. Black (WG chair). Also Bert Wijnen has reviewed this document for the IESG. In addition, Brian Haberman has done a review for the INT Area as requested by WG-chair (David Black) via Margaret Wasserman. Note to RFC Editor - Make sure the abstract lists the RFCs that will be obsoleted: OLD: Abstract This document specifies the way of encapsulating IPv6, IPv4 and ARP packets over Fibre Channel. This document specifies also the method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on Fibre Channel networks, and a mechanism to perform IPv4 address resolution over Fibre Channel networks. NEW: Abstract This document specifies the way of encapsulating IPv6, IPv4 and ARP packets over Fibre Channel. This document specifies also the method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on Fibre Channel networks, and a mechanism to perform IPv4 address resolution over Fibre Channel networks. This document obsoletes RFC2625 and RFC3831. - In the acknowledgement section pls add a few more acknowledgements: OLD: The authors would like to acknowledge the ANSI INCITS T11.3 Task Group members who reviewed this document as well as the authors of [RFC-2625] and [RFC-3831]. NEW: The authors would like to acknowledge the ANSI INCITS T11.3 Task Group members who reviewed this document as well as the authors of [RFC-2625] and [RFC-3831]. The authors also thank the IMSS WG and Brian Haberman for their review and comments. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Definitions of Managed Objects for FCIP' to Proposed Standard
The IESG has approved the following document: - 'Definitions of Managed Objects for FCIP ' draft-ietf-ips-fcip-mib-09.txt as a Proposed Standard This document is the product of the IP Storage Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-mib-09.txt-09.txt Technical Summary This document defines a portion of the Management Information Base (MIB). It specifies objects for managing FCIP (Fibre Channel over TCP/IP) entities (RFC 3821), which are used to interconnect FC fabrics with IP networks. Working Group Summary The working group reached consensus on the MIB. The group hoped to have the MIB reviewed and published around the same time as RFC 3821, but it turned out the MIB review was not possible in the timeframe. Protocol Quality The working group's MIB advisor was Keith McCloghrie. The MIB Doctor was Bert Wijnen. There were two revisions of the MIB addressing review comments. The WG Chair shepherd is David Black, taking over from his former co-Chair, Elizabeth Rodriguez. Allison Mankin is the Responsible Area Director. Notes to RFC Editor Title, Abstract and Introduction: please expand the first use of FC and FCIP in each. Please make these expansions consistent with the expansions used in RFC 3821. Security Considerations OLD: In particular, write access to fcipDiscoveryDomainName and fcipEntityAddress can cause a loss of reachability to portions of the SAN NEW: In particular, write access to fcipDiscoveryDomainName and fcipEntityAddress can cause a loss of reachability to portions of the Fibre Channel fabric ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Remote Network Monitoring Management Information Base Version 2' to Draft Standard
The IESG has approved the following document: - 'Remote Network Monitoring Management Information Base Version 2 ' draft-ietf-rmonmib-rmon2-v2-05.txt as a Draft Standard This document is the product of the Remote Network Monitoring Working Group. Additional information: Implementation Report can be accessed at http://www.ietf.org/IESG/Implementations/RFC2021-Implementation.txt This document obsoletes RFC 2021, updates RFC 3273 and contains a new version of the RMON2-MIB module. This document is the product of the Remote Network Monitoring Working Group. The IESG contact persons are Bert Wijnen and David Kessens. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-rmon2-v2-05.txt Technical Summary This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices. This document obsoletes RFC 2021, updates RFC 3273 and contains a new version of the RMON2-MIB module. Working Group Summary Working group has consensus on this document. There was quite extensive discussion on the clarification of the TimeFilter TEXTUAL-CONVENTION. Protocol Quality This document has been reviewed for the IESG by Bert Wijnen. Implementation Report can be accessed at http://www.ietf.org/IESG/Implementations/RFC2021-Implementation.txt Notes to RFC-Editor: In abstract, pls change: OLD: This document obsoletes RFC 2021 and the RMON2-MIB module contained in this memo obsoletes the RMON2-MIB module at RFC3273 level. NEW: This document obsoletes RFC 2021, updates RFC 3273 and contains a new version of the RMON2-MIB module. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail' to Proposed Standard
The IESG has approved the following document: - 'Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail ' draft-ietf-lemonade-mms-mapping-06.txt as a Proposed Standard This document is the product of the Enhancements to Internet email to support diverse service environments Working Group. The IESG contact persons are Ted Hardie and Scott Hollenbeck. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-mms-mapping-06.txt Technical Summary The cellular telephone industry has defined a service known as the Multimedia Messaging Service (MMS). This service uses formats and protocols which are similar to, but differ in key ways from those used in Internet mail. This document specifies how to exchange messages between these two services, including mapping information elements as used in MMS X-Mms-* headers as well as delivery and disposition reports, to and from that used in ESMTP and Internet message headers. Working Group Summary The LEMONADE working group came to consensus on the publication of this document. No issues were raised during IETF Last Call. This work was coordinated with 3GPP and 3GPP2 by the author and working group chairs. The document was approved, but the approval appealed by John Klensin. After considering the appeal, the IESG asked the working group to consider the issues raised. This document contains the changes made by the working group post-appeal and after a second IETF Last Call. Protocol Quality This work was reviewed for the IESG by Ted Hardie. Eric Burger and Glenn Parsons are the PROTO shepherds. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'A PRF API extension for the GSS-API' to Proposed Standard
The IESG has approved the following documents: - 'A PRF API extension for the GSS-API ' draft-ietf-kitten-gssapi-prf-07.txt as a Proposed Standard - 'A PRF for the Kerberos V GSS-API Mechanism ' draft-ietf-kitten-krb5-gssapi-prf-04.txt as a Proposed Standard These documents are products of the Kitten (GSS-API Next Generation) Working Group. The IESG contact persons are Sam Hartman and Russ Housley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-prf-07.txt Technical Summary These documents define a Pseudo-Random Function (PRF) extension to the Generic Security Service Application Programming Interface (GSS-API) for keying application protocols given an established GSS-API security context and provide an implementation of that extension for the Kerberos V mechanism. The primary intended use of this function is to key secure session layers that don't or cannot use GSS-API per- message MIC (message integrity check) and wrap tokens for session Working Group Summary The Kitten working group participants are solidly behind this document. There were two areas of contention during its development. First, representatives of the Samba team desired that the PRF be designed to be compatible with the key export methods implemented by Microsoft for use with CIFS. The working group consensus was that following Microsoft's direction would have compromised the security and usefulness of the PRF functionality. Second, there was a desire to include a Java Binding for the prf() method. The Java Binding was removed from the document due to both a technical disagreement within the working group related to how it should be implemented as well as conflicts between IETF and Java Community Process processes. Protocol Quality There are no shipping implementations of this extension although there has been broad review and no concerns have been raised regarding the ability to implement the interfaces defined. Several vendors including MIT's Kerberos team, Heimdal and Sun Microsystems have indicated a desire to implement the extension. Ken Raeburn, Uri Blumenthal and Joe Salowey provided significant review. This document has been reviewed for the IESG by Sam hartman. Note to RFC Editor In draft-ietf-kitten-krb5-gssapi-prf, replace the citation to [rfc1964] with a citation to [cfx] and remove the reference entry for [rfc1964] Just before section 2, delete the paragraph beginning mechanisms may limit the output and ending with requested. In draft-ietf-kitten-gssapi-prf, replace the reference to RFC 1750 with a reference to RFC 4086. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Approval of application/xenc+xml Media Type
The IESG has approved a request to register the application/xenc+xml MIME media type in the standards tree. This media type is a product of the World Wide Web Consortium (W3C). The IESG contact persons are Ted Hardie and Scott Hollenbeck. The registration template can be found at this location on the W3C web site: http://www.w3.org/TR/xmlenc-core/#sec-MediaType-Registration ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4261 on Common Open Policy Service (COPS) Over Transport Layer Security (TLS)
A new Request for Comments is now available in online RFC libraries. RFC 4261 Title: Common Open Policy Service (COPS) Over Transport Layer Security (TLS) Author(s): J. Walker, A. Kulkarni, Ed. Status: Standards Track Date: December 2005 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 14 Characters: 28662 Updates:2748 I-D Tag:draft-ietf-rap-cops-tls-11.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4261.txt This document describes how to use Transport Layer Security (TLS) to secure Common Open Policy Service (COPS) connections over the Internet. This document also updates RFC 2748 by modifying the contents of the Client-Accept message. This document is a product of the Resource Allocation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. 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. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4261.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4287 on The Atom Syndication Format
A new Request for Comments is now available in online RFC libraries. RFC 4287 Title: The Atom Syndication Format Author(s): M. Nottingham, Ed., R. Sayre, Ed. Status: Standards Track Date: December 2005 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 43 Characters: 81922 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-atompub-format-11.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4287.txt This document specifies Atom, an XML-based Web content and metadata syndication format. This document is a product of the Atom Publishing Format and Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. 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. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4287.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4279 on Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)
A new Request for Comments is now available in online RFC libraries. RFC 4279 Title: Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) Author(s): P. Eronen, Ed., H. Tschofenig, Ed. Status: Standards Track Date: December 2005 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 15 Characters: 32160 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-tls-psk-09.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4279.txt This document specifies three sets of new ciphersuites for the Transport Layer Security (TLS) protocol to support authentication based on pre-shared keys (PSKs). These pre-shared keys are symmetric keys, shared in advance among the communicating parties. The first set of ciphersuites uses only symmetric key operations for authentication. The second set uses a Diffie-Hellman exchange authenticated with a pre-shared key, and the third set combines public key authentication of the server with pre-shared key authentication of the client. This document is a product of the Transport Layer Security Working Group of the IETF. This is now a Proposed Standard Protocol. 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. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4279.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4296 on The Architecture of Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) on Internet Protocols
A new Request for Comments is now available in online RFC libraries. RFC 4296 Title: The Architecture of Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) on Internet Protocols Author(s): S. Bailey, T. Talpey Status: Informational Date: December 2005 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 22 Characters: 43907 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-rddp-arch-07.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4296.txt This document defines an abstract architecture for Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) protocols to run on Internet Protocol-suite transports. This architecture does not necessarily reflect the proper way to implement such protocols, but is, rather, a descriptive tool for defining and understanding the protocols. DDP allows the efficient placement of data into buffers designated by Upper Layer Protocols (e.g., RDMA). RDMA provides the semantics to enable Remote Direct Memory Access between peers in a way consistent with application requirements. This document is a product of the Remote Direct Data Placement Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4296.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'UMAC: Message Authentication Code using Universal Hashing' to Informational RFC
The IESG has approved the following document: - 'UMAC: Message Authentication Code using Universal Hashing ' draft-krovetz-umac-07.txt as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Russ Housley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-krovetz-umac-07.txt Technical Summary This specification describes how to generate an authentication tag using the UMAC message authentication algorithm. UMAC is designed to be very fast to compute in software on contemporary uniprocessors. Measured speeds are as low as one cycle per byte. UMAC relies on addition of 32-bit and 64-bit numbers and multiplication of 32-bit numbers; all of these operations are well-supported by contemporary computers. Working Group Summary This document is not affiliated with any working group; however, the document received considerable review and comment on the CFRG mailing list. The document was updated to reflect the discussion. Protocol Quality At least one implementation exists. See http://www.cs.ucdavis.edu/~rogaway/umac/. Note to RFC Editor Please replace the first paragraph of the Introduction as follows: OLD: UMAC is a message authentication algorithm (MAC) designed for high performance. It it backed by a rigorous formal analysis and there are no intellectual property claims made to any ideas used in its design. NEW: UMAC is a message authentication algorithm (MAC) designed for high performance. It is backed by a rigorous formal analysis and there are no intellectual property claims made by any of the authors to any ideas used in its design. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
