Re: Last Call: Change the status of ADSP (RFC 5617) to Internet Standard
On 10/2/2013 5:04 PM, Murray S. Kucherawy wrote: On Wed, Oct 2, 2013 at 7:41 AM, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from an individual participant to make the following status changes: - RFC5617 from Proposed Standard to Historic The supporting document for this request can be found here: http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/ [...] I support this change, for the reasons articulated in the request and in this thread. I am the lead developer and maintainer of OpenDKIM, an open source implementation of DKIM and related standards, including VBR, ADSP, the recent REPUTE work, and some others. It is widely deployed, including use at a few of the largest operators. An informal survey was done on one of the mailing lists where this package is supported, asking which operators do ADSP queries and which act upon the results. I have so far only received a half dozen answers to this, but the consensus among them is clear: All of the respondents either do not check ADSP, or check it but do nothing with the results. One operator puts disposition of messages based on ADSP results into the hands of its users, but no statistics were offered about how many of these users have ADSP-based filtering enabled. That same operator intends to remove that capability once this status change goes into effect. -MSK I don't believe this would be a fair assessment of industry wide support -- using only one API to measure. There are other APIs and proprietary systems who most likely are not part of the OpenDKIM group. There are commercial operations using DKIM and ADSP is part of it. The interop problem is clearly due intentional neglect by specific MLS (Mailing List Software) of the DKIM security protocol, not because of the protocol itself. Support of the protocol does not cause an interop problem -- it helps support the DKIM security protocol.The ADSP (RFC5617) protocol is part of the DKIM security threat mitigation model (RFC4686), the DKIM Service Architecture (RFC5585), the DKIM Deployment Guide (RFC5863) and also the Mailing List for DKIM guideline (rfc6377). That is FOUR documents. Applicability and Impact reports *should* to be done before pulling the rug from under the non-OpenDKIM market feet. In addition, it appears part of the request is to help move an alternative DMARC protocol forward. Why would the DMARC replacement do better? Why should commercial development for ADSP be stopped and removed from products, and now a new investment for DMARC be done? Would this resolve the apparent interop problem with the specific Mailing List Software who refuse to support a DKIM security protocol? More importantly, why should any small operator and participant of the IETF continue to support IETF projects if their support is ignored and projects will be ended without their input or even explaining why it should be ended? That doesn't play well for the IETF Diversity Improvement Program. -- HLS
Re: Last Call: Change the status of ADSP (RFC 5617) to Internet Standard
Hi. Just to be sure that everyone has the same understanding of what is being proposed here, the above says to Historic but the writeup at http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/ says to Internet Standard. Can one or the other be corrected? Gakk. I don't know how that happened. I'll see if the Secretariat can fix it. I'm sure it's my fault.. Noting that this has been fixed and that a revised Last Call note went out. Please, if you continue this discussion, change the subject line to say Historic instead of Internet Standard, so no one is confused by the dissonance. Thanks, all, and my apologies again for the error in the title. Barry
Re: Last Call: Change the status of ADSP (RFC 5617) to Internet Standard
On Oct 3, 2013, at 4:53 AM, Hector Santos hsan...@isdg.net wrote: On 10/2/2013 5:04 PM, Murray S. Kucherawy wrote: On Wed, Oct 2, 2013 at 7:41 AM, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from an individual participant to make the following status changes: - RFC5617 from Proposed Standard to Historic The supporting document for this request can be found here: http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/ [...] I support this change, for the reasons articulated in the request and in this thread. I am the lead developer and maintainer of OpenDKIM, an open source implementation of DKIM and related standards, including VBR, ADSP, the recent REPUTE work, and some others. It is widely deployed, including use at a few of the largest operators. An informal survey was done on one of the mailing lists where this package is supported, asking which operators do ADSP queries and which act upon the results. I have so far only received a half dozen answers to this, but the consensus among them is clear: All of the respondents either do not check ADSP, or check it but do nothing with the results. One operator puts disposition of messages based on ADSP results into the hands of its users, but no statistics were offered about how many of these users have ADSP-based filtering enabled. That same operator intends to remove that capability once this status change goes into effect. -MSK I don't believe this would be a fair assessment of industry wide support -- using only one API to measure. There are other APIs and proprietary systems who most likely are not part of the OpenDKIM group. There are commercial operations using DKIM and ADSP is part of it. The interop problem is clearly due intentional neglect by specific MLS (Mailing List Software) of the DKIM security protocol, not because of the protocol itself. Support of the protocol does not cause an interop problem -- it helps support the DKIM security protocol.The ADSP (RFC5617) protocol is part of the DKIM security threat mitigation model (RFC4686), the DKIM Service Architecture (RFC5585), the DKIM Deployment Guide (RFC5863) and also the Mailing List for DKIM guideline (rfc6377). That is FOUR documents. Applicability and Impact reports *should* to be done before pulling the rug from under the non-OpenDKIM market feet. In addition, it appears part of the request is to help move an alternative DMARC protocol forward. Why would the DMARC replacement do better? Why should commercial development for ADSP be stopped and removed from products, and now a new investment for DMARC be done? Would this resolve the apparent interop problem with the specific Mailing List Software who refuse to support a DKIM security protocol? More importantly, why should any small operator and participant of the IETF continue to support IETF projects if their support is ignored and projects will be ended without their input or even explaining why it should be ended? That doesn't play well for the IETF Diversity Improvement Program. Dear Hector, Indeed, more should be said about underlying reasons. The reason for abandoning ADSP is for the same reason few providers reject messages not authorized by SPF records ending in -all (FAIL). Mailing-List software existed long before either of these strategies and domains using mailing lists need to be excluded from having DMARC policies (until a revised ATPS specification able to use normal signatures is published.) The reason for moving toward DMARC is, although aligned policy is only suitable for domains limited to messages of a transactional nature, places where one authorization scheme fails can be mostly recovered by the other which greatly increases the chances of a domain's policy being applied in the desired fashion. Regards, Douglas Otis
Re: Last Call: Change the status of ADSP (RFC 5617) to Internet Standard
On Thu, Oct 3, 2013 at 4:53 AM, Hector Santos hsan...@isdg.net wrote: I don't believe this would be a fair assessment of industry wide support -- using only one API to measure. There are other APIs and proprietary systems who most likely are not part of the OpenDKIM group. There are commercial operations using DKIM and ADSP is part of it. I would hope this is obvious, but I didn't claim my little survey was representative of the entire industry. It's at best a cross section of OpenDKIM's user base (which does include at least three of the largest operators, but by no means all of them). I made it clear how many replies I'd gotten. Applicability and Impact reports *should* to be done before pulling the rug from under the non-OpenDKIM market feet. In addition, it appears part of the request is to help move an alternative DMARC protocol forward. Why would the DMARC replacement do better? Why should commercial development for ADSP be stopped and removed from products, and now a new investment for DMARC be done? Would this resolve the apparent interop problem with the specific Mailing List Software who refuse to support a DKIM security protocol? The ADSP impact reports that are part of RFC6377, the writeup for this action, and elsewhere already exist and are not specific to one implementation. I don't think there's any particular DMARC-specific agenda here, but it is indeed obvious that (a) they overlap in a few ways, and (b) DMARC has not yet been accepted as IETF work but already has more deployment and support momentum than ADSP ever enjoyed. More importantly, why should any small operator and participant of the IETF continue to support IETF projects if their support is ignored and projects will be ended without their input or even explaining why it should be ended? That doesn't play well for the IETF Diversity Improvement Program. I think it's rather premature to claim anyone's input has been ignored when the solicitation for comment is still open. -MSK
Re: Last Call: Change the status of ADSP (RFC 5617) to Internet Standard
On 10/2/2013 11:46 AM, John C Klensin wrote: I assume we will need to agree to disagree about this, but... --On Wednesday, October 02, 2013 10:44 -0700 Dave Crocker d...@dcrocker.net wrote: If a spec is Historic, it is redundant to say not recommended. As in, duh... Duh notwithstanding, we move documents to Historic for many reasons. Sure. And you seem to think that it's important to publish an RFC that documents the reasons. You seem to think that it will somehow affect later handling of the historic document. While an entirely reasonable theoretical premise, I'm not aware of its having any empirical basis. Quite the opposite. Further since your proposal constitutes additional work for someone, the benefit of doing it should be clear and compelling. So far, what you've offered is neither. In fact, the general view around the IETF is that the rest of the world deals with RFCs in a very coarse and inclusive manner, so that your proposal for fine-grained, formal documentation of rationales and the like constitutes mere noise to the rest of the world. The situation would be different if a huge amount of additional work were involved but it seems to me that almost all of the required explanation is already in the write-up and that the amount of effort required to approve an action consisting of a document and a status change is the same as that required to approve the status change only. While it's laudable that you are volunteering to do this negligible extra work that will cause negligible amounts of additional delay, it still suffers the problem of producing negligible additional benefit. If someone is all that interested in the reason the spec was moved to Historic, they can consult the IETF archives. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Last Call: Change the status of ADSP (RFC 5617) to Internet Standard
The IESG has received a request from an individual participant to make the following status changes: - RFC5617 from Proposed Standard to Historic The supporting document for this request can be found here: http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/ I'm one of the authors of this RFC and support the change. ADSP was basically an experiment that failed. It has no significant deployment, and the problem it was supposed to solve is now being addressed in other ways. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly
Re: Last Call: Change the status of ADSP (RFC 5617) to Internet Standard
--On Wednesday, October 02, 2013 07:41 -0700 The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from an individual participant to make the following status changes: - RFC5617 from Proposed Standard to Historic The supporting document for this request can be found here: http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to- historic/ Hi. Just to be sure that everyone has the same understanding of what is being proposed here, the above says to Historic but the writeup at http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/ says to Internet Standard. Can one or the other be corrected? After reading the description at the link cited above and assuming that Historic is actually intended, I wonder, procedurally, whether a move to Historic without document other than in the tracker is an appropriate substitute for the publication of an Applicability Statement that says not recommended and that explains, at least in the level of detail of the tracker entry, why using ADSP is a bad idea. If there were no implementations and no evidence that anyone cared about this, my inclination would be to just dispose of RFC 5617 as efficiently and with as little effort as possible. But, since the tracker entry says that there are implementations and that misconfiguration has caused harm (strongly implying that there has even been deployment), it seems to me that a clear and affirmative not recommended applicability statement is in order. thanks, john
Re: Last Call: Change the status of ADSP (RFC 5617) to Internet Standard
Hi. Just to be sure that everyone has the same understanding of what is being proposed here, the above says to Historic but the writeup at http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/ says to Internet Standard. Can one or the other be corrected? Gakk. I don't know how that happened. I'll see if the Secretariat can fix it. I'm sure it's my fault.. Sigh. Barry
RE: Last Call: Change the status of ADSP (RFC 5617) to Internet Standard
Hi, The subject lines says the intention is to move to Internet Standard; the text says the intention is to move to Historic. This Last Call should probably be re-published with matching intent. David Harrington ietf...@comcast.net +1-603-828-1401 -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce- boun...@ietf.org] On Behalf Of The IESG Sent: Wednesday, October 02, 2013 10:42 AM To: IETF-Announce Subject: Last Call: Change the status of ADSP (RFC 5617) to Internet Standard The IESG has received a request from an individual participant to make the following status changes: - RFC5617 from Proposed Standard to Historic The supporting document for this request can be found here: http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/ The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-10-30. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The affected document can be obtained via http://datatracker.ietf.org/doc/rfc5617/ IESG discussion of this request can be tracked via http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to- historic/ballot/
Re: Last Call: Change the status of ADSP (RFC 5617) to Internet Standard
On 10/2/2013 9:28 AM, John C Klensin wrote: After reading the description at the link cited above and assuming that Historic is actually intended, I wonder, procedurally, whether a move to Historic without document other than in the tracker is an appropriate substitute for the publication of an Applicability Statement that says not recommended and that explains, at least in the level of detail of the tracker entry, why using ADSP is a bad idea. This suggestion has the dual potential benefits of being inefficient and ineffective. If a spec is Historic, it is redundant to say not recommended. As in, duh... Even better is that an applicability statement is merely another place for the potential implementer to fail to look and understand. Anyone who fails to understand the implications of Historic (or fails to find the correct status) is not going to be better at finding and understanding an applicability statement. ADSP is only worthy of a small effort, to correct its status, to reflect its current role in Internet Mail. Namely, its universal non-use within email filtering. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Last Call: Change the status of ADSP (RFC 5617) to Internet Standard
I assume we will need to agree to disagree about this, but... --On Wednesday, October 02, 2013 10:44 -0700 Dave Crocker d...@dcrocker.net wrote: If a spec is Historic, it is redundant to say not recommended. As in, duh... Duh notwithstanding, we move documents to Historic for many reasons. RFC 2026 lists historic as one of the reasons a document may be not recommended (Section 3.3(e)) but says only superceded... or is for any other reason considered to be obsolete about Historic (Section 4.2.4). That is entirely consistent with Maturity Levels and Requirement Levels being basically orthogonal to each other, even if Not Recommended and Internet Standard are presumably mutually exclusive. Even better is that an applicability statement is merely another place for the potential implementer to fail to look and understand. Interesting. If a potential implementer or other potential user of this capability fails to look for the status of the document or protocol, then the reclassification to Historic won't be found and this effort is a waste of the community's time. If, by contrast, that potential user checks far enough to determine that the document has been reclassified to Historic, why is it not desirable to point that user to a superceding document that explains the problem and assigns as requirement status of not recommended? The situation would be different if a huge amount of additional work were involved but it seems to me that almost all of the required explanation is already in the write-up and that the amount of effort required to approve an action consisting of a document and a status change is the same as that required to approve the status change only. If creating an I-D from the write-up is considered too burdensome and it would help, I'd be happy to do that rather than continuing to complain. ADSP is only worthy of a small effort, to correct its status, to reflect its current role in Internet Mail. Namely, its universal non-use within email filtering. If the specification had been universally ignored, I'd think that a simple status change without further documentation was completely reasonable. However, the write-up discusses harm caused by incorrect configuration and by inappropriate use, real cases, and effects from posts from users. That strongly suggests that this is a [mis]feature that has been sufficiently deployed to cause problems, not someone that is universally non-used. And that, IMO, calls for a explanation --at least to the extent of the explanation in the write-up-- as to why ADSP was a bad idea, should be retired where it is used, and should not be further deployed. best, john
Re: Last Call: Change the status of ADSP (RFC 5617) to Internet Standard
On Wed, Oct 2, 2013 at 7:41 AM, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from an individual participant to make the following status changes: - RFC5617 from Proposed Standard to Historic The supporting document for this request can be found here: http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/ [...] I support this change, for the reasons articulated in the request and in this thread. I am the lead developer and maintainer of OpenDKIM, an open source implementation of DKIM and related standards, including VBR, ADSP, the recent REPUTE work, and some others. It is widely deployed, including use at a few of the largest operators. An informal survey was done on one of the mailing lists where this package is supported, asking which operators do ADSP queries and which act upon the results. I have so far only received a half dozen answers to this, but the consensus among them is clear: All of the respondents either do not check ADSP, or check it but do nothing with the results. One operator puts disposition of messages based on ADSP results into the hands of its users, but no statistics were offered about how many of these users have ADSP-based filtering enabled. That same operator intends to remove that capability once this status change goes into effect. -MSK
Last Call: Change the status of ADSP (RFC 5617) to Internet Standard
The IESG has received a request from an individual participant to make the following status changes: - RFC5617 from Proposed Standard to Historic The supporting document for this request can be found here: http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/ The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2013-10-30. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The affected document can be obtained via http://datatracker.ietf.org/doc/rfc5617/ IESG discussion of this request can be tracked via http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/ballot/
