Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14

["Murray S. Kucherawy" <[e-mail]>]

On Fri, May 17, 2013 at 11:16 AM, Scott Kitterman <[e-mail]>wrote:

> Based on this, I changed it to:
>
>           ADMDs that wish to declare that no hosts are authorized to use
> their
>           DNS domain names in the HELO or MAIL FROM commands during SMTP
>           sessions can publish SPF records that say so for domain names
> that
>           are neither used in the domain part of email addresses nor
> expected
>           to originate mail.
>

Better.  Could be better still if it weren't one sentence spanning five
lines, but I can live with it.


> > > Looking at
> > >
> http://www.iana.org/assignments/dns-parameters/dns-parameters.xml#dns-para
> > > meters-6, I agree that many of these DNS errors could
> > > be permanent, but the spec calls for temperror in these cases.
> > >
> > > The only temporary errors that turned out to really be permanent that
> I've
> > > seen in the wild are some SERVFAIL (2).
> >
> > As in a server that constantly returns SERVFAIL?  I imagine that just
> like
> > in any context, a temporary error that's constantly returned is
> eventually
> > de facto treated as permanent insofar as the client gives up and goes
> away.
> >
> > > If we were starting from scratch, I'd probably classify many of the
> other
> > > rcodes as permanent errors, but we aren't.  Absent some evidence of
> this
> > > causing real world problems, I think we need to leave it the way it is.
> >
> > I think this is an error that warrants correction.  It might be
> interesting
> > to know what some implementations have done here, e.g., if implementers
> > decided to implement based on RFC1035 rather than RFC4408.
>
> All of the ones I know of make anything not 0 or 3 a temperror.  I agree
> it's
> wrong, but is it an error that, in operation, causes any problems?  If
> not, I
> don't think we should fix it.
>

I guess.  I'd rather it be correct, and the operations ADs or DNSDIR review
might pick on this, but maybe not.


> The number was extracted from the usual location.
>
> OK, not that.
>
> Is it common to justify design decisions like this in the draft of the
> text?
>

In my experience, it's essential, even if it's from the usual location.
"We picked this number as a guess and it seemed to work well" is fine, but
how do we know 15 or 25 wouldn't have been better choices?  We might be
challenged on that if we don't say something.


> Might this be better for sm's write up than the actual draft?
>

No.  The shepherd writeup would be where he says something like "Consensus
agreed with 20, but there were several people who felt it should be {lower,
higher, random, purple}." It's information for the IESG, but it's not
something your average reader will go and find.


> > I looked through the collected grammar in there and didn't see anything
> > that covered CIDR expressions.  Now that my eyes have un-crossed, did you
> > have specific one(s) there in mind?
>
> I was looking at 3.2.2, which (you are correct) defines IPv4/IPv6, but not
> CIDR
> (I lost track of which one we were discussing), sorry.
>
> Unfortunately RFC 4632 doesn't have an ABNF.
>

So back to my suggestion: What about 1*2DIGIT and 1*3DIGIT?

-MSK