Re: Document Action: 'US Secure Hash Algorithms (SHA and HMAC-SHA)' to Informational RFC
Tony, yes, I believe that would be fine. The best would be to ask debian-legal (or a similar community) to review it. They have experience in evaluating software licenses. I'll forward the updated language to them, and will relay any responses that indicate a problem. Generally, it is unfortunate and problematic to create new licenses. Incompatibilities and problems have a history of turning up later on. I believe the IETF should adopt a specific permissive license for its publications to avoid this problem. The license should be reviewed by the community. If people are interested in this topic, please participate in the IPR working group. Regards, Simon Tony Hansen <[EMAIL PROTECTED]> writes: > If this sentence were changed to read: > >Royalty free license to copy and use this software is granted, >provided that redistributed derivative works do not contain >misleading author or version information. > > would that satisfy your concerns? The new wording is similar to the > phrasing found in the comparable statement in punycode's RFC 3492. > > Tony Hansen > [EMAIL PROTECTED] > > Simon Josefsson wrote: >> >> The license in section 1.1 reads: >> >>Royalty free license to copy and use this software is granted >>provided that this document is identified in all material >>mentioning or referencing this software. >> >> I believe this part of the license is incompatible with some licenses >> used to implement IETF protocols. It has the same problem as the >> advertisement clause in the old BSD license. It is thus questionable >> whether the document achieve its stated goal. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Meeting Survey Results
And only 7% say that the $50US fee hike might stop them attending again. With so many people unhappy with wireless, these stats add up to charging more for better wireless The weird stat was 7% for whom $50US extra means they have to file paperwork to get the money (just eat less? :) I meant to follow up on this sooner - sorry... I've worked for two employers that had $500 limits on credit card expenditures (beyond that, you had to either turn in check requests or use your own credit card). Reimbursement wasn't the issue, the issue was that the employers were trying to limit card use to something that was most likely business-related (so, for instance, I couldn't go buy a car with my corporate card) and not too likely to blow a budget without manager signoff until it was too late. The weird stat was that this seems to be a one-size-fits-all number, at least per-company - the employers couldn't figure out how to change my limit to $650 so I could register late without needing special processing, without changing the limit for other employees as well. Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Appeal of the IESG decision to publish draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 To the Internet Architecture Board, as per the Internet Standards Process, section 6.5, and on behalf of the SPF project, I am hereby appealing the IESG's decision[2] on 2005-12-08 to publish the draft-lyon-senderid-core-01 I-D[3] as an Experimental RFC as-is. I am attaching my initial IESG appeal[1] and will try not to rehash all the arguments contained therein. I will merely point out the larger issues and the negative implications of the IESG's decision here. Please review the IESG appeal and the referenced documents first. The Problem === The IESG decision is wrong in two ways: 1. On a technical level, draft-lyon-senderid-core-01[3], by implicitly redefining the semantics of "v=spf1" DNS records, significantly conflicts with draft-schlitt-spf-classic-02[4], on which the former depends, and which has also been approved by the IESG to be published as an Experimental RFC. The IESG has conceded this fact in their response[2] to my appeal, yet they argue that "the IESG did consider this conflict in its original discussions, and that is one of the reasons why we crafted the original IESG note to be included in these documents, which highlights that there are concerns about using these mechanisms in tandem". No such note can sufficiently mitigate the technical conflict. Even though the IESG has only approved the drafts for Experimental status, the experiments they are approving are still in conflict. This conflict bears the potential of disrupting the e-mail operation of domain owners participating in either of the experiments despite their careful consideration of the experiments' rules. The IESG, under- standably, does not want to take sides for political reasons, but difficult political situations should not bar the internet standards process from producing technically sound results. The conflict arose only after the IESG asked for individual draft submissions from the SPF and Sender ID authors and draft-lyon-senderid- core-00 was submitted (which for the first time included the re-inter- pretation of "v=spf1" records for the PRA identity). Accepting such a submission despite the prior consensus of the MARID WG[5] (which was closed afterwards) that "v=spf1" should not be used for checking of PRA clearly violates the ultimate goal of producing reliable standards. 2. On an operational level, SPF has been an ongoing experiment since late 2003. In their response to my appeal, the IESG explained that the SPF and Sender ID drafts "were approved for publication as Experimental RFCs and not approved for the Standards track", and that "the bar is lower for Experimental RFCs". Ted Hardie, the IETF AD responsible for these drafts, explained[6] that "the conflicts between the two [drafts] on this and other points are part of why the IESG is publishing them 'AS IS'". This reasoning disregards the substantial history the "v=spf1" record definition has had outside the IETF since late 2003[7]. The SPF project, which I am representing in this case, believes that the decision to ignore the prior experience with SPFv1 and to lodge draft-schlitt-spf-classic for Experimental instead of Proposed Standard status was unjustified, but has accepted the IESG's decision that additional experience be gathered before standardizing the proposal. However the IESG's decision to equally publish a draft-lyon-senderid- core that, without technical reason, conflicts with the historical use of "v=spf1" records, unnecessarily compromises at least one of the two experiments. Meaningful and reliable experience about the practicability and effectiveness of draft-schlitt-spf-classic cannot be reasonably expected to be collected when at the same time draft-lyon-senderid-core misinterprets the semantics of "v=spf1" records in a significant number of cases. Requiring participants in the SPFv1 experiment to "opt out" from also participating in the Sender ID experiment by publishing an empty "spf2.0" record cannot be considered an acceptable solution either, both based on principle and given the large number of existing "v=spf1" records that were published before Sender ID was conceived[8]. Finally, the IESG's approval of conflicting experiments could be seen as a failure in following the standards process[9], which in section 4.2.1, "Experimental", requires "verification that there has been adequate coordination with the standards process", which would by analogy not only mean coordination with standards track RFCs but also with other experimental RFCs. Both SPFv1 and Sender ID could certainly be used productively in tandem if the redefinition of "v=spf1" records was omitted from the Sender ID specification. Proposed Remedy === The
Re: Appeal of the IESG decision to publish draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02
Dear Mr. Mehnle, This is to acknowledge receipt of your message. The IAB will review the material and provide you a response. Best regards, Leslie, IAB Chair. Julian Mehnle wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 To the Internet Architecture Board, as per the Internet Standards Process, section 6.5, and on behalf of the SPF project, I am hereby appealing the IESG's decision[2] on 2005-12-08 to publish the draft-lyon-senderid-core-01 I-D[3] as an Experimental RFC as-is. I am attaching my initial IESG appeal[1] and will try not to rehash all the arguments contained therein. I will merely point out the larger issues and the negative implications of the IESG's decision here. Please review the IESG appeal and the referenced documents first. The Problem === The IESG decision is wrong in two ways: 1. On a technical level, draft-lyon-senderid-core-01[3], by implicitly redefining the semantics of "v=spf1" DNS records, significantly conflicts with draft-schlitt-spf-classic-02[4], on which the former depends, and which has also been approved by the IESG to be published as an Experimental RFC. The IESG has conceded this fact in their response[2] to my appeal, yet they argue that "the IESG did consider this conflict in its original discussions, and that is one of the reasons why we crafted the original IESG note to be included in these documents, which highlights that there are concerns about using these mechanisms in tandem". No such note can sufficiently mitigate the technical conflict. Even though the IESG has only approved the drafts for Experimental status, the experiments they are approving are still in conflict. This conflict bears the potential of disrupting the e-mail operation of domain owners participating in either of the experiments despite their careful consideration of the experiments' rules. The IESG, under- standably, does not want to take sides for political reasons, but difficult political situations should not bar the internet standards process from producing technically sound results. The conflict arose only after the IESG asked for individual draft submissions from the SPF and Sender ID authors and draft-lyon-senderid- core-00 was submitted (which for the first time included the re-inter- pretation of "v=spf1" records for the PRA identity). Accepting such a submission despite the prior consensus of the MARID WG[5] (which was closed afterwards) that "v=spf1" should not be used for checking of PRA clearly violates the ultimate goal of producing reliable standards. 2. On an operational level, SPF has been an ongoing experiment since late 2003. In their response to my appeal, the IESG explained that the SPF and Sender ID drafts "were approved for publication as Experimental RFCs and not approved for the Standards track", and that "the bar is lower for Experimental RFCs". Ted Hardie, the IETF AD responsible for these drafts, explained[6] that "the conflicts between the two [drafts] on this and other points are part of why the IESG is publishing them 'AS IS'". This reasoning disregards the substantial history the "v=spf1" record definition has had outside the IETF since late 2003[7]. The SPF project, which I am representing in this case, believes that the decision to ignore the prior experience with SPFv1 and to lodge draft-schlitt-spf-classic for Experimental instead of Proposed Standard status was unjustified, but has accepted the IESG's decision that additional experience be gathered before standardizing the proposal. However the IESG's decision to equally publish a draft-lyon-senderid- core that, without technical reason, conflicts with the historical use of "v=spf1" records, unnecessarily compromises at least one of the two experiments. Meaningful and reliable experience about the practicability and effectiveness of draft-schlitt-spf-classic cannot be reasonably expected to be collected when at the same time draft-lyon-senderid-core misinterprets the semantics of "v=spf1" records in a significant number of cases. Requiring participants in the SPFv1 experiment to "opt out" from also participating in the Sender ID experiment by publishing an empty "spf2.0" record cannot be considered an acceptable solution either, both based on principle and given the large number of existing "v=spf1" records that were published before Sender ID was conceived[8]. Finally, the IESG's approval of conflicting experiments could be seen as a failure in following the standards process[9], which in section 4.2.1, "Experimental", requires "verification that there has been adequate coordination with the standards process", which would by analogy not only mean coordination with standards track RFCs but also with other experimental RFCs. Both SPFv
