Re: Legal Provisions Relating to IETF Documents
Hi, On 2008-09-09 01:28 Ray Pelletier said the following: > All > > The redline of the Legal Provisions Relating to IETF Documents dated > 9-8-08 has been uploaded to http://trustee.ietf.org/policyandprocedures.html > in doc, pdf and rtf formats. To see what changes would be needed in 'idnits', I've looked over the instructions for text to be included in IETF documents (Section 6 of the document referred to above). I see that Section 6.a. specifies the following text: This Internet-Draft is submitted to IETF pursuant to, and in full conformance with, the provisions of [BCP 78 and 79]. and also Section 6.b. specifies this text: Copyright [year] IETF Trust and the persons identified as its authors. All rights reserved. This document is subject to BCP [78] and [the IETF Trust’s Legal Provisions Relating to IETF Documents in effect on the date of publication of this document]. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. So here are my questions: It is clear to me that in the text above, the notation "[year]" is not meant to be literal, but should be replaced with the current year. However, what is the meaning of "[BCP 78 and 79]"? If it is meant to be included verbatim, it could be meant to indicate that there should be a reference in the reference section called "BCP 78 and 79", or maybe two references called "BCP 78" and "BCP 79"? But then we come to the second paragraph of the 6.b. text, which has the text "BCP [78]" -- is this now meant to refer to a reference called "78"? Finally, there's the "[the IETF Trust’s Legal Provisions Relating to IETF Documents in effect on the date of publication of this document]" -- is that meant to be replaced by a reference to the actual document in effect at that day, or is it meant to be inserted verbatim in the documents? I'm afraid that it isn't at all clear to me exactly what the boilerplate as specified by this revision of the Legal Provisions document should look like. I'd suggest the following: * Say explicitly that the notation [year] should be replaced by the year the document is submitted or published, and likewise for any other text that should be replaced. * Remove any other "[" and "]" characters from text that must be included verbatim. * If it is required that references to BCP 78 and BCP 79 be included in the document's reference section, say so explicitly. * Indicate whether it is permissible to add reference annotation, in the style otherwise used for references in the document, to the boilerplate, or whether that should not be done. (Don't force the document author to use a particular style of reference annotation, such as "[BCP 78]" if the rest of the document uses "[1]", "[2]", etc. ). Regards, Henrik ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Strong Opposition due to spam backscatter. Re: Last Call: draft-ietf-sieve-refuse-reject-07 and -08 (Sieve Email Filtering: Reject and Extended Reject Extensions) to Proposed Standard
This is an argument opposing the proposal to have the IETF's IESG make draft-ietf-sieve-refuse-reject-07 a Proposed Standard (i.e. RFC). Sieve is widely used for email processing; it competes with procmail and other rules-processing systems. My reason for opposing -07 and drafting and supporting -08 is this: In plain English, the specification up for vote (-07) allows compliant email system implementations to continue to be a source for vast amounts of spam, while the current draft (-08) does not. Support for ereject (in the form of a successful ) MUST be a clear message to users that the implementation used actually is a modern implementation that successfully avoids sending floods of unsolicited MDNs (spam) by rejecting messages during the SMTP transaction (instead of accepting them and then sending MDNs back to the alleged sender) wherever possible, thereby reducing the backscatter problem. If a system implementing the specs we're working on works on a store-and-forward basis, then it MUST NOT MISLEAD, i.e. LIE TO ITS USERS by claiming to support the enhanced standard we are writing. -07 allows an implementation to mislead its users by claiming to support enhanced functionality when it does no such thing. That would simply be dishonest. Archaic implementations are free to support the old SIEVE - RFC 3028. -07 needs to be rectified so that the intro from earlier versions remains true: > This document updates the definition of "reject" to require rejecting > messages during the SMTP transaction (instead of accepting them and > then sending MDNs back to the alleged sender) wherever possible, > thereby reducing the problem. (Where 'possible' does NOT include the > case where the reject string is one that cannot be sent during the > SMTP transaction.) I wonder if Ned and I have argued past each other. AFAICT Ned is arguing that he/Sun must be allowed to continue to send unsolicited MDNs (even when the reject string is ASCII, and there is one recipient) e.g. when Sun's server is used with someone else's LMTP server. And yet he claims that I'm misrepresenting his implementation and the reasoning behind it. (It's hard to know what he thinks, as he repeatedly avoid answering my questions.) Ned acts like saying that I'm against allowing Japanese users to fall back to out-of-transaction rejects when non-ASCII reject strings need to be used. I'm not. Look at the drafts I wrote! They don't do that! Obviously, a developer cannot control how his product is deployed by a customer. Consider a Sieve implementation within an SMTP server that is hidden behind a store-and-forward SMTP proxy; call this whole system "B". It's beyond the control of the developer of SMTP server software to prevent a customer from creating a system like "B". Any SMTP server can be hidden thus. However, as authors of the Sieve implementation, we can specify what it can and cannot be connected to. We specify how and when SMTP servers deliver their messages to recipients, by transmitting the messages only to specified systems, after all. Naysayers say otherwise, but provide no argument. What I am trying to restore is the demand that a)any SMTP (or LMTP) server software implementing this Sieve extension be capable of performing in-transaction ereject and b) that if such software is incorporated into a larger system by a customer, that that customer not claim that that system, if it is like "B", supports ereject, because that would be dishonest. The software should cause to fail in such a case, either because of a configuration option the the customer sets (truthfully, one hopes) or by detecting that it has been deployed in such a system, or a combination (e.g. a smart installation script could poke around and if appropriate, ask: This would ensure that the system does not LIE TO ITS USERS. It would alert the customer to the issue, perhaps leading them to abandon the store-and-forward system for a modern one. Tim Polk just mentioned "I would encourage the authors to add a brief discussion describing why rejecting messages before delivery is better than accepting and bouncing them. " There was such a discussion in an earlier draft. It was removed by the author of -07. I've restored it in -08 (which I'm about to submit to the queue). Tim also says "Consider noting that silent discard of legitimate messages constitutes denial of service and that determination of a forged return-path should be performed very carefully. " This is true. Likewise, sending MDNs containing spam and viruses also has security implications. Both need to be mentioned. I believe all the nits and other issues that have been raised need to be addressed; a WGLC and LC are also needed. I think it's generally recognized that MDN backscatter is bad. Now, not all backscatter is MDNs, but e.g. Justin Mason has said > [Backscatter is] nearly as big a problem as direct spam, nowadays; t
Re: The RFC Editor and the Internet Standards Process
- Original Message - From: "SM" <[EMAIL PROTECTED]> To: Cc: <[EMAIL PROTECTED]> Sent: Tuesday, September 09, 2008 12:56 PM Subject: The RFC Editor and the Internet Standards Process > Hello, > > A proposal was posted at > http://www.iab.org/documents/resources/RFC-Editor-Model.html about a > new structure for the RFC Editor. I read about the Internet > Standards Process and couldn't find the answer to a question. > > Quoting Section 4.2.3 of RFC 2606: > > "The RFC Editor is expected to exercise his or her judgment > concerning the editorial >suitability of a document for publication with Experimental or >Informational status, and may refuse to publish a document which, in >the expert opinion of the RFC Editor, is unrelated to Internet >activity or falls below the technical and/or editorial standard for >RFCs." This creates a liabilty for the Editor that may not be reasonable. > > Furthermore, > >".. the IESG and the RFC Editor have agreed that the RFC Editor >will refer to the IESG any document submitted for Experimental or >Informational publication which, in the opinion of the RFC Editor, >may be related to work being done, or expected to be done, within the >IETF community." > > Given that the RFC Editor is explicitly mentioned in RFC 2026, does > RFC 2606 have to be revised to bring it in line with the proposed > structure? > > Regards, > -sm > > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.169 / Virus Database: 270.6.19/1662 - Release Date: 9/9/2008 10:47 AM ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: RFC2183 to obsolete RFC1806
On Sep 8, 2008, at 5:06 AM, John C Klensin wrote: > > Please reserve Last Calls for situations in which community > input or demonstrations of community consensus are actually > needed. Perhaps an announcement specifically calling out the approval of the errata would have been better. I was trying to make sure there was a public record of the intent or fait accompli of obsoleting RFC1806 -- since errata don't normally have IETF-announce postings associated. Thanks, Lisa ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Encoding of extention marker
Hi All,
Can any one tell me whether the extention marker will be encoded for the
below structure or not.
SAEBearerToBeSetupItemCtxtSUReqIEs S1AP-PROTOCOL-IES ::= {
{ ID id-SAEBearerToBeSetupItemCtxtSUReq CRITICALITY reject TYPE
SAEBearerToBeSetupItemCtxtSUReq PRESENCE mandatory },
...
}
Regards
Bivu
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: [rfc-i] The RFC Editor and the Internet Standards Process
On Sep 9, 2008, at 9:56 PM, SM wrote: Hello, A proposal was posted at http://www.iab.org/documents/resources/RFC-Editor-Model.html about a new structure for the RFC Editor. I read about the Internet Standards Process and couldn't find the answer to a question. Quoting Section 4.2.3 of RFC 2606: "The RFC Editor is expected to exercise his or her judgment concerning the editorial suitability of a document for publication with Experimental or Informational status, and may refuse to publish a document which, in the expert opinion of the RFC Editor, is unrelated to Internet activity or falls below the technical and/or editorial standard for RFCs." Furthermore, ".. the IESG and the RFC Editor have agreed that the RFC Editor will refer to the IESG any document submitted for Experimental or Informational publication which, in the opinion of the RFC Editor, may be related to work being done, or expected to be done, within the IETF community." Given that the RFC Editor is explicitly mentioned in RFC 2026, does RFC 2606 have to be revised to bring it in line with the proposed structure? I would argue that 2026 does not need to be revised. The model discribes the collective of functions that taken together we call "The RFC Editor". Various people have already commented that using the same words for one of the functions is confusing. More to the point 4.2.3 is about what we have started to call the independent submissions and it is the Independent Submission Editor function in the model that takes the responsibilities that are described in the paragraph above. Also see RFC4844 and RFC4846. --Olaf PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
