Subject: Re: [spfbis] Stephen Farrell's No Objection on draft-ietf-spfbis-4408bis-19: (with COMMENT)

From: S Moonesamy <[email-masked]>
Date: Thu, 12 Sep 2013 07:29:37 -0700

Hello,

Could the SPFBIS WG please address the following comment?

Thanks,
S. Moonesamy (as document shepherd)

At 03:15 12-09-2013, Stephen Farrell wrote:
>Stephen Farrell has entered the following ballot position for
>draft-ietf-spfbis-4408bis-19: No Objection
>
>When responding, please keep the subject line intact and reply to all
>email addresses included in the To and CC lines. (Feel free to cut this
>introductory paragraph, however.)
>
>
>Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
>for more information about IESG DISCUSS and COMMENT positions.
>
>
>The document, along with other ballot positions, can be found here:
>http://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis/
>
>
>
>----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------
>
>
>- 4.1: given that recursion is allowed and that you have
>overall limits on how many DNS transactions can be done,
>is the "transactions-remaining" value also an implicit
>parameter of a check_host() call? This is only a comment
>since check_host is not a formal API but it'd seem to make
>it easier to get right if you make that implicit parameter
>explicit. Or do the limits apply to each call as you
>recurse?  That wasn't entirely clear to me.
>
>- I didn't get appendix D at all - what's that do?
>
>- Appendix E.1, 2nd bullet: what's that? I think it needs
>a reference if you want it to be understood.

---

From: S Moonesamy <[email-masked]>
Date: Wed, 25 Sep 2013 13:30:47 -0700

Hello,

I would like to bring the message below to the attention of the 
working group.  There has not been any response to it.  Can a SPFBIS 
WG participant please respond to the message?

Thanks,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 25 Sep 2013 14:23:42 -0700

On Wed, Sep 25, 2013 at 1:30 PM, S Moonesamy <[email-masked]> wrote:

> Hello,
>
> I would like to bring the message below to the attention of the working
> group.  There has not been any response to it.  Can a SPFBIS WG participant
> please respond to the message?
>
>
> Thanks,
>> Please refer to http://www.ietf.org/iesg/**statement/discuss-criteria.**
>> html <http://www.ietf.org/iesg/statement/discuss-criteria.html>
>> http://datatracker.ietf.org/**doc/draft-ietf-spfbis-4408bis/<http://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis/>
>>
>>
>>
>> ------------------------------**------------------------------**
>> ----------
>> COMMENT:
>> ------------------------------**------------------------------**
>> ----------
>>
>>
I suggest that it would be sufficient to add some prose that says the
"transactions-remaining" count (or whatever we call it) has to apply
through the recursions.  We shouldn't make this look any more like an API
definition than it already does.

I agree, we should explain it and include an example, or drop it.  Someone
closer to the implementation and the original material than I am is almost
certainly able to come up with an appropriate example versus what I would
invent.

>> a reference if you want it to be understood.
Same here; examples would probably be useful for all three sections.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Wed, 25 Sep 2013 21:23:56 -0400

> At 03:15 12-09-2013, Stephen Farrell wrote:

For our implementation, it was a plug and play update and hence a 
global limit per check_host instance call.  So its not done on a per 
domain basis although it is possible to load a per domain 
configuration. I don't know of anyone on our end (nor it is 
interesting for anyone to tell us what they are using) doing a per 
domain limit.

BTW, for us CHECK_HOST() is an API and it takes submitter (RFC4405) 
MAIL FROM values:

    spf_result = CHECK_HOST(MAILFROM [,HELO] [,SUBMITTER])

Thats an integrator POV this SPFBIS draft refused to acknowledge.  I 
don't get it, but I accept it.

>> - I didn't get appendix D at all - what's that do?

Same here.  You have to guess what its talking about with the starting 
sentence. I guess its about a method to track/log calls.

>> a reference if you want it to be understood.

Overall, this Appendix E should be an BCP, i.e., what is a 
"specialized DNS server" but.... Personally, these sections intro can 
be written better. They need some sort of intros into what they are 
about.  Probably restate what are the problems, deployment or SPF 
"applied" issues the outlined items are addressing.

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 26 Sep 2013 01:09:59 -0400

On Wednesday, September 25, 2013 14:23:42 Murray S. Kucherawy wrote:
> >> http://datatracker.ietf.org/**doc/draft-ietf-spfbis-4408bis/<http://datat
> >> racker.ietf.org/doc/draft-ietf-spfbis-4408bis/>
> >> 
> >> 
> >> 

I agree that staying away from more API like language is good.  I took a prose 
approach to describing this was a global limit and not a per-recursion limit.  
In the attached diff.

> certainly able to come up with an appropriate example versus what I would

It made sense in context before we reorganized the document.  I find it 
troubling that the author of the reorganization now doesn't understand part of 
the text he shuffled around.

I'll take a stab at adding something.

> Same here; examples would probably be useful for all three sections.

Generically, I agree, but it's beyond me to right it tonight.  I think the 
information is all there to get someone started with concepts of how senders 
can deal with avoiding SPF problems related to forwarding.  These are all 
unchanged from RFC 4408.  I don't think we should be changing them now after 
all the reviews as it wouldn't be a small change to rework these sections as 
you suggest.

Full diff from -20 attached.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 25 Sep 2013 22:57:57 -0700

> I'll take a stab at adding something.

That was unnecessary, Scott.  Furthermore, I didn't say I don't understand
it.  I merely suggested that someone (you perhaps) might already have an
example in mind, perhaps from previous revisions or related work, rather
than one I might contrive.

> all the reviews as it wouldn't be a small change to rework these sections

In what sense does adding an example, illustrative of the point being made,
constitute "rework"?  I'd be more than surprised if adding examples causes
a full round of evaluation again.

In any case, Stephen's comments were non-blocking (note COMMENT, not
DISCUSS), so they're merely suggestions to improve or clarify.  I think
they're useful suggestions, but if it's really so arduous to do so, we can
drop it.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 26 Sep 2013 02:10:32 -0400

On Wednesday, September 25, 2013 22:57:57 Murray S. Kucherawy wrote:
> > > I agree, we should explain it and include an example, or drop it.
> >  
> >  Someone
> >  
> > > closer to the implementation and the original material than I am is
> > 
> > almost
> > 

It's probably me being tired.  Sorry.

I disagree with removing text at this point that we've carried forward from 
RFC 4408.  I couldn't think of a way to come up with short examples.  It's not 
that what's there needs to be changed, but that an example that would make it 
easy to understand would take a lot of text that I'm just too tired to write 
tonight.

Maybe when I'm better rested it'll be clearer to me how to do it in a more 
simple manner.

Scott K