Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
I'm having a hard time with both sides of the argument, especially the supposed existence of a interop problem which seems to only to be highlighted to procedurally stump the SPF type advocates. I don't believe there was an adequate answer from the advocates of removing the SPF RR type and the repeated assertion that its been discussed at length has not resolved the issue because it really hasn't been appropriately address. Its not convincing. This is the reason the issue will not go away. My take is that the the initial MARID design expectations where being met and to me, that is a very important design consideration in all this; what were the original expectations with a TXT/SPF migration. Although very slowly, there were some deployments administratively and technically. In my estimation, the WG did receive positive support that there was sincere interest in adding support for the SPF record type primarily because there was some level of adoption discovered during the interop report work. You can include us (SSI) as having interest in enabling/adding SPF record support. I recommend the following to basically allow IMPLEMENTATORS to decide: 1) Continue with the TXT/SPF migration plan, 2) Address any technical protocol issue with using an SPF type, 3) Add implementation designs notes on the pros and cons. This will allow coders to add the optimized logic for usage. It will also allow for new problem solving seeds to be laid down. It will hopefully get the DNS software vendors to finally add direct support for unnamed TYPE support (query and passthru). Finally, which is what I have been trying to get - why hasn't the IETF taking this issue (unnamed type support) very serious? The reason I wonder because if the DNS vendors don't address this, then to me, that should be the only reason to remove the SPF type or even bother with any new RR type concept. The interop problem cited about RFC 4408 is not convincing to me. The only reason my package as an early adopter didn't have SPF support was purely for short term optimizations and lack of servers with unnamed type processing support reasons - no mas. -- HLS On Mon, Aug 19, 2013 at 4:08 PM, Andrew Sullivan a...@anvilwalrusden.comwrote: Note that I am not the shepherd for this draft, but I am the WG co-chair. On Mon, Aug 19, 2013 at 05:05:21PM +0200, Måns Nilsson wrote: * The charter disallows major protocol changes -- removing the SPF RR type is a direct charter violation; since SPF is being used on the Internet. That argument doesn't work, because the WG had to make a major protocol change in this area no matter what, since 4408 has an interoperability problem. If you wish to argue that the WG decided on the wrong protocol change, that line is open to you; but nobody can argue that the change is wrong because of our charter. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com -- hls
Re: 2119bis
On 8/30/11, Murray S. Kucherawy m...@cloudmark.com wrote: Mark Nottingham: 1) I agree that the SHOULD... UNLESS pattern ought be documented. I had never thought of this before. I kind of like the idea, especially since SHOULD has always meant MUST unless you really know what you're doing Such an odd reading. Does it mean you MUST because you could not handle it otherwise? It takes two to tango. One side reasons can be different than the other. If a software breaks down because it read SHOULD as a MUST and expected the other end will also view is a MUST, then it didn't know what it was doing. Things break down. Implementors on either side can't depend on it and need to function in lieu of it. There is always the possibility one decided Na, not needed, not worth the cost. Its not required. etc, and no one should die because of that decision. I think it MUST be noted that a Minimum Implementation for a protocol is all anyone can expect. If a SHOULD item is among the listed minimum requirements, it MUST be removed from the list or changed to a MUST. Maybe the term Minimum Implementation (is part of, is not part of) can be incorporated into each of the key word text. -- hls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
On 8/30/11, Keith Moore mo...@network-heretics.com wrote: On Aug 30, 2011, at 9:24 AM, Marshall Eubanks wrote: Personally I think 2119 is just fine and doesn't need to be updated. Keith +1 -- hls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
In the perfect written technical specification, if you pulled out all the SHOULDs, the protocol still survives. But if a required functionality breaks down, then it wasn't well written. On 8/30/11, Eric Burger ebur...@standardstrack.com wrote: Can you give an example of where a dangling SHOULD makes sense? Most often I see something like: SHOULD implement security meaning SHOULD implement security, unless you do not feel like it or are in an authoritarian regime that bans security On Aug 30, 2011, at 12:11 PM, Keith Moore wrote: On Aug 30, 2011, at 12:06 PM, Marc Petit-Huguenin wrote: The meaning of SHOULD is clear for the authors (it mean[s] that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.), the problem is that some implementers use a different meaning (I do not have to implement this if it is inconvenient or difficult for me to implement), vendors another one (SHOULD gave us the right to not implement it). I even read somewhere, perhaps on this list, about a vendor that rejected any bug report against a SHOULD. Conditional MUST, in my opinion, does not have this problem. But conditional MUST has other problems, namely that you have to enumerate the exceptions for the MUST, and that's not always practical. Implementors who think that SHOULD gives them a free pass to avoid implementing something that's needed to interoperate are misreading 2119. But document editors should avoid using SHOULD for cases where failure to implement the requirement will result in interoperability failure. I could see maybe posting an erratum or a brief update to 2119, but I think that reopening that document in general is a Very bad Idea. And for existing documents that misuse SHOULD, the appropriate thing to do is to update those documents or post errata to those documents, rather than try to retroactively change the meaning of the keywords in those documents. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- hls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
+1 I believe the issue is the subtle differences between: SHOULD for something new, i.e. no dependency SHOULD for something old, i.e. an enhancement or new dependency the engineer is trying to push hard. As much as we want to isolate protocols, in practice, we are integrating many protocols and in theory, it should all work. I believe it has for the most part. But increasingly a protocol upgrade or new protocol here requires a MUST USAGE dependency of another otherwise optional protocol there. I believe that is what we are seeing with this new interpretation. New protocol X works better if existing optional (and much older) protocol Y is applied as a SHOULD. It would like to say MUST but it can't because Y is already optional and not required. This new interpretation will make software implementing X non-compliant if it also doesn't support Y. --- HLS On Mon, Aug 29, 2011 at 10:44 PM, Eric Burger ebur...@standardstrack.com wrote: Yes, and... I would offer that for most cases, If Y then MUST X or If Z then MUST NOT X *are* what people usually mean when they say SHOULD. In the spirit of Say What You Mean, a bare SHOULD at the very least raise an ID-nit, suggesting to the author to turn the statement into the if Y then MUST X or if Z then MUST NOT X form. Being pedantic and pedagogic: SHOULD send a 1 UNLESS you receive a 0 really means UNLESS you receive a 0, one MUST send a 1. My vision of the UNLESS clause is not necessarily a protocol state, but an environment state. These are things that I can see fit the SHOULD/UNLESS form: SHOULD send a 1 UNLESS you are in a walled garden SHOULD flip bit 27 UNLESS you have a disk SHOULD NOT explode UNLESS you are a bomb are all reasonable SHOULD-level statements. I would offer that ANY construction of SHOULD without an UNLESS is a MAY. Unless of course one considers us the Protocol Nanny's(tm) - if do not do a SHOULD, we will send you to bed without your treacle! I.e., there IS NO DISTINCTION BETWEEN A BARE SHOULD AND A MAY. On Aug 29, 2011, at 9:47 PM, ned+i...@mauve.mrochek.com wrote: Hi - From: Eric Burger eburge...@standardstrack.com To: Narten Thomas nar...@us.ibm.com; Saint-Andre Peter stpe...@stpeter.im Cc: IETF discussion list ietf@ietf.org Sent: Monday, August 29, 2011 3:08 PM Subject: Re: 2119bis I would assume in the text of the document. This paragraph is simply an enumeration of Burger's Axiom: For every SHOULD, there must be an UNLESS, otherwise the SHOULD is a MAY. I disagree. I concur with your disagreement. SHOULD should *not* be used when the list of exceptions is known and practically enumerable. If the UNLESS cases can be fully enumerated, then SHOULD x UNLESS y is equivalent to WHEN NOT y MUST X. (Both beg the question of whether we would need to spell out that WHEN y MUST NOT X is not necessarily an appropriate inference.) RFC 2119 SHOULD is appropriate when the UNLESS cases are known (or suspected) to exist, but it is not practical to exhaustively identify them all. Let's not gild this lily. +1 Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- hls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
On Mon, Aug 29, 2011 at 11:11 PM, Keith Moore mo...@network-heretics.com wrote: On Aug 29, 2011, at 10:44 PM, Eric Burger wrote: I would offer that ANY construction of SHOULD without an UNLESS is a MAY. The essential beauty of SHOULD is that it gets specification writers and working groups out of the all-too-common rathole of trying to anticipate and nail down every exceptional case. Keith +1, and thats the problem with this new interpretation and its unwritten form has already been used in a WG to label a group participants as 2119 illiterates and any software that has implemented a SHOULD as already non-compliant. -- hls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
