Subject: [spfbis] AD Review of draft-ietf-spfbis-4408bis-17

From: Pete Resnick <[email-masked]>
Date: Wed, 14 Aug 2013 15:11:04 -0500

Folks,

I first want to apologize for the inordinate and unacceptable delay in 
processing the publication request. Between the IETF meeting and some 
personal travel, I just failed to prioritize this appropriately.

That said, my AD Review of the document is done and I'm pleased to say 
that I am very happy with the document. Well done! I have a few comments 
below, but none of them warrant holding up the document from Last Call. 
I will initiate that today and will put the document (tentatively) on 
the IESG telechat in two weeks.

Also note: All of the items below are comments, not demands. Please 
treat these as you would any other WG participant's comments. If what I 
suggest goes against WG consensus, the answer to me should be "Thanks, 
but we'll pass on that one."

So, for your edification:

---

2.5 and forward: You introduce the term "operator" without ever defining 
it. Most of the time, operator refers to the deployer of the SPF record. 
Other times, operator refers to the interpreter. I think using two 
different terms throughout the document (neither of which is "operator") 
would be better.

2.6: I've never been clear why this section isn't simply part of section 
4, but that's simply an editorial preference.

2.6.1: Reference to "TXT records" here doesn't make sense. Prior to 
this, all references have been to "SPF records" (which is fine), and it 
isn't until section 4 that you mention TXT records at all. Either strike 
"TXT" or replace it with "SPF".

3.4: s/falling/failing

4.6.1: A forward reference to sections 5 & 6 would be helpful to tell 
readers that the definitions of mechanisms and modifiers appear later.

5: I think "ptr" should be separated out. The current notation in 
parentheses is not very clear. I suggest something like:

    There is an additional designated sender mechanism that was defined
    in the earlier experimental version of this specification, but for
    reasons described in section 5.x, it SHOULD NOT be used:

       ptr

Similar text should appear in 5.5, and maybe even in 7.2. If you make 
this change, moving 5.5 to the end of section 5 would also make sense.

6:

    The modifiers defined in this document ("redirect" and "exp") MAY
    appear anywhere in the record, but SHOULD appear at the end, after
    all mechanisms.

That use of MAY and SHOULD together isn't correct. You can either 
replace the "MAY" with "can", or rewrite the sentence:

    The modifiers defined in this document ("redirect" and "exp") SHOULD
    appear at the end of the record, after all mechanisms, though
    syntactically they can appear anywhere in the record.

7.3:

      *DIGIT = zero or more digits
       r     = reverse value, splitting on dots by default

For some reason, those equal signs bother me. (They look too much like 
part of the ABNF.) I suggest either a "-" or a ":", or just tabbing over 
instead. It's no big deal either way.

8.2: I suggest changing "A 'neutral' result MUST be treated exactly like 
the 'none' result;" to "A 'neutral' result is operationally equivalent 
to a 'none' result". The MUST doesn't seem to be making an 
interoperability claim.

9: I really dislike the use of the word "forensic" in this section. The 
first can simply be removed. The second can be changed to "reconstructive".

14.1: Why is RFC 1983 a normative reference? I will call it out in the 
Last Call just in case, but it seems perfectly reasonable for this to be 
informative.

E.3, second bullet: s/MAY/can

---

That's it. You should feel free to treat these as Last Call comments and 
buffer them until Last Call is complete, but if you have responses to 
any of them, please let me know.

Thanks again for a solid document.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: S Moonesamy <[email-masked]>
Date: Wed, 14 Aug 2013 14:15:51 -0700

At 13:11 14-08-2013, Pete Resnick wrote:
>That said, my AD Review of the document is done and I'm pleased to 
>say that I am very happy with the document. Well done! I have a few 
>comments below, but none of them warrant holding up the document 
>from Last Call. I will initiate that today and will put the document 
>(tentatively) on the IESG telechat in two weeks.

Pete, thanks for the AD review.

>treat these as you would any other WG participant's comments. If 
>what I suggest goes against WG consensus, the answer to me should be 
>"Thanks, but we'll pass on that one."

As a note to the working group, please comment about the review.

>14.1: Why is RFC 1983 a normative reference? I will call it out in 
>the Last Call just in case, but it seems perfectly reasonable for 
>this to be informative.

During my review I asked "What is a valid fully qualified 
domain?".  Dave Crocker suggested citing RFC 1983.  Would the working 
group be okay with moving the RFC 1983 reference to Informative?

Regards,
S. Moonesamy (as document shepherd)

---

From: Pete Resnick <[email-masked]>
Date: Wed, 14 Aug 2013 16:20:56 -0500

On 8/14/13 4:15 PM, S Moonesamy wrote:
> During my review I asked "What is a valid fully qualified domain?".  
> Dave Crocker suggested citing RFC 1983.  Would the working group be 
> okay with moving the RFC 1983 reference to Informative?

I also notice that 5782 is normatively referenced, and that is almost 
certainly just an error.

If there are no objections, I'll just move those two from normative to 
informative in an RFC Editor note and explain in the Last Call.

pr

---

From: S Moonesamy <[email-masked]>
Date: Wed, 14 Aug 2013 14:34:06 -0700

Hi Pete,
At 14:20 14-08-2013, Pete Resnick wrote:
>I also notice that 5782 is normatively referenced, and that is 
>almost certainly just an error.

The RFC 5782 normative  reference is an error.  Scott Kitterman 
mentioned that he would fix it in -18.

>If there are no objections, I'll just move those two from normative 
>to informative in an RFC Editor note and explain in the Last Call.

I am waiting for the working group to comment on the other reference.

Regards,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 14 Aug 2013 16:26:13 -0700

On Wed, Aug 14, 2013 at 2:20 PM, Pete Resnick <[email-masked]>wrote:

>> During my review I asked "What is a valid fully qualified domain?".  Dave
>> Crocker suggested citing RFC 1983.  Would the working group be okay with
>> moving the RFC 1983 reference to Informative?
>>
>

It's cool that I get to say this to an IESG member:

No objection.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 16 Aug 2013 22:21:59 -0400

Comments inline.

Scott K

> different terms throughout the document (neither of which is "operator")

Actually it's the other way around.  The only time it's in reference to the 
sending side of the equation is the initial reference.  If it would help, I 
think we could change the first one to DNS operator and the rest to SPF verifier 
operator.  I'm not sure this is worth fixing, so I'll wait for feedback.

> 4, but that's simply an editorial preference.

I think of section 2 as more about what and section 4 more about how, but what 
we have now is roughly consistent with RFC 4408, so we shouldn't change it 
without a good reason.

> "TXT" or replace it with "SPF".

Now it has, "(b) no TXT records were retrieved from the DNS that appeared to 
be intended for use by SPF verifiers."  That's another way of saying SPF 
records.  If we were to replace the current text, it would be "(b) no SPF 
records were retrieved from the DNS."  Is that better?

> 3.4: s/falling/failing

Fixed locally

> readers that the definitions of mechanisms and modifiers appear later.

Added locally.

> this change, moving 5.5 to the end of section 5 would also make sense.

We had stronger text about this at one point, but went back to where we are 
now.  A verifier still needs to implement ptr processing for backward 
compatibility, so from an implementation perspective, it is still required.  I 
don't think we ought to segregate it out like this.

>     syntactically they can appear anywhere in the record.

IIRC, we had struggled with this a bit, I think this is a good formulation.  
Changed locally.

> instead. It's no big deal either way.

This is almost exactly what was in RFC 4408.  It had:

   Optional transformers are the following:

      *DIGIT = zero or more digits
      'r'    = reverse value, splitting on dots by default

I've gone ahead and changed my local copy to add the quotes back to 'r', but I 
don't think we should change it further.  I'm open to being wrong on that.  
What do others think?

> to a 'none' result". The MUST doesn't seem to be making an

We debated this extensively in the working group.  There were arguments in 
favor of more extensive treatment of receiver policy and arguments in favor of 
removing even the very limited text about it that was in RFC 4408.  In the 
end, we compromised on leaving it just like RFC 4408, which is what this is.  
The interoperability argument is that if receivers treat neutral more harshly 
than than none, it would be an impediment to deployment.

> first can simply be removed. The second can be changed to "reconstructive".

Done.

> Last Call just in case, but it seems perfectly reasonable for this to be

It's used as a reference in the ABNF:

domain           = <fully qualified domain as per [RFC1983]>

I had put it as normative for that reason.  Given that, is it still OK to move 
it?

> E.3, second bullet: s/MAY/can

Done.

> I also notice that 5782 is normatively referenced, and that is almost

As mentioned by sm, I've already corrected this locally for the to be -18.

> any of them, please let me know.

See above.  I do have a few questions in response to the comments.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Fri, 16 Aug 2013 19:56:45 -0700

Hi Scott,

Thanks for responding to the comments.

>I had put it as normative for that reason.  Given that, is it still 

I'll comment on this so that the IETF Last Call can be initiated.

In Section 4.4 there is:

   "Properly formed domains are fully qualified domains as defined
    in [RFC1983]"

I suggest moving the RFC 1993 reference to informative with the 
following changes:

    Properly formed domains are fully qualified domains as defined
    in RFC 1035.

In Appendix A:

    domain    = <fully qualified domain as per [RFC1035]>

Regards,

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 16 Aug 2013 23:03:16 -0400

>    domain    = <fully qualified domain as per [RFC1035]>

OK. I just wanted to make sure that everyone knew it was in the ABNF.  I'll change it locally. 

To be clear: Do you want me to post -18 before you start IETF Last Call or are you starting it with -17?

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Fri, 16 Aug 2013 20:23:35 -0700

Hi Scott,
>ABNF.  I'll change it locally.

Thanks.

>Call or are you starting it with -17?

Could you please submit -18?  I'll ask Pete Resnick to use -18 for 
the Last Call.  I'll edit the document shepherd write-up and remove 
the sentence mentioning RFC 1983.

Regards,

---

From: Pete Resnick <[email-masked]>
Date: Sat, 17 Aug 2013 08:12:22 -0500

[Skipping the obvious bits that you're just fixing, and the ABNF 
discussion we're having elsewhere.]

On 8/16/13 9:21 PM, Scott Kitterman wrote:
> sending side of the equation is the initial reference.

No. The initial use is section 2.5. In that one, it's the verifier, not 
the DNS operator. In 2.6.6 and 2.6.7, I think the operator in question 
is the DNS operator. In 8, it's the verifier. In 8.7, it's the DNS 
operator. In 9, both occurrences are the verifier. In 11.7 it's the 
verifier. In H.3 and H.4, it looks like all six references are to the 
verifier.

> If it would help, I

I will leave it up to the WG. I think it's a bit confusing, but not a 
huge deal.

> we have now is roughly consistent with RFC 4408, so we shouldn't change it

Understood.

> records were retrieved from the DNS."  Is that better?

That would be my preference.

> don't think we ought to segregate it out like this.

If this was a conscious decision of the WG, I will defer.

> don't think we should change it further.  I'm open to being wrong on that.

This is purely editorial nonsense, so I'm happy to leave it as it was in 
4408.

> than than none, it would be an impediment to deployment.

Well, "impediment to deployment" here is more of a psychological issue 
than a technical issue. But I'm not willing to re-open a big debate 
about this. If this is what the WG settled on, I'll hold my nose. :-)

pr

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 17 Aug 2013 09:48:16 -0400

On Saturday, August 17, 2013 08:12:22 Pete Resnick wrote:
> > think we could change the first one to DNS operator and the rest to SPF
> > verifier operator.  I'm not sure this is worth fixing, so I'll wait for
> > feedback.

I think I'd prefer to leave it.  I can see how it's not 100% clear, but I 
think it's reasonably so from context.  I'm afraid if I change it now, I'll 
worsen it.  Anyone else have an opinion?  I don't feel strongly about it.

> > I think of section 2 as more about what and section 4 more about how, but
> > what we have now is roughly consistent with RFC 4408, so we shouldn't
> > change it without a good reason.
> 
> Understood.
> 
> > Now it has, "(b) no TXT records were retrieved from the DNS that appeared
> > to be intended for use by SPF verifiers."  That's another way of saying
> > SPF records.  If we were to replace the current text, it would be "(b) no
> > SPF records were retrieved from the DNS."  Is that better?
> 

Done.

> > compatibility, so from an implementation perspective, it is still
> > required.  I don't think we ought to segregate it out like this.
> 

I'm going to leave it as is unless someone else suggests I should do 
otherwise.

> > I've gone ahead and changed my local copy to add the quotes back to 'r',
> > but I don't think we should change it further.  I'm open to being wrong
> > on that. What do others think?
> 
> > favor of more extensive treatment of receiver policy and arguments in
> > favor of removing even the very limited text about it that was in RFC
> > 4408.  In the end, we compromised on leaving it just like RFC 4408, which
> > is what this is. The interoperability argument is that if receivers treat
> > neutral more harshly than than none, it would be an impediment to
> > deployment.
> 

Thanks.

I've also gone ahead and applied Hector's typo fixes.

I've attached an rfcdiff from the published -18 to my local copy of the to be 
-19 so we can ensure we're on the same page before I upload it.  Let me know 
if I got it right.

Scott K

---

From: John Leslie <[email-masked]>
Date: Sat, 17 Aug 2013 17:49:24 -0400

Scott Kitterman <[email-masked]> wrote:
>>> Actually it's the other way around.  The only time it's in reference to
>>> the sending side of the equation is the initial reference.
>> 
>>... 
> think it's reasonably so from context.

   IMHO, if Pete and you can read it differently, I think it should be
clarified. At the very least, the term now refers to different actors.

> I'm afraid if I change it now, I'll worsen it.

   It's much better to face that problem now.

--
John Leslie <[email-masked]>

---

From: Pete Resnick <[email-masked]>
Date: Sat, 17 Aug 2013 17:46:52 -0500

> -19 so we can ensure we're on the same page before I upload it.  Let me know

This looks fine. I'll leave it to SM to give you the official go-ahead, 
but with this I'm happy to put it out for Last Call. Anything 
outstanding from my comments are things that the WG can decide on just 
as any other comments that come in during Last Call. No reason to hold 
anything up. As soon as you get the OK from SM, post -19 and I'll assume 
that -19 is the one to Last Call.

pr

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 18 Aug 2013 00:03:12 -0400

>    It's much better to face that problem now.

Makes sense.  I'll wait and see what sm says, although you now tipped my 
feeling in the direction of I should change it.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Sat, 17 Aug 2013 22:25:43 -0700

Hi Scott,
At 15:46 17-08-2013, Pete Resnick wrote:
>This looks fine. I'll leave it to SM to give you the official 
>go-ahead, but with this I'm happy to put it out for Last Call. 
>Anything outstanding from my comments are things that the WG can 
>decide on just as any other comments that come in during Last Call. 
>No reason to hold anything up. As soon as you get the OK from SM, 
>post -19 and I'll assume that -19 is the one to Last Call.

I would follow John Leslie's suggestion (see 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03907.html 
).  Here's what I suggest:

  (i)  Submit version -19 so that Pete Resnick can start the Last Call.

  (ii) Propose text on the SPFBIS mailing list for the change.

Regards,

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 18 Aug 2013 06:53:10 -0400

Done.

>   (ii) Propose text on the SPFBIS mailing list for the change.

Proposed changes attached for comment.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Wed, 28 Aug 2013 01:44:37 -0700

Hi Scott,
>worsen it.  Anyone else have an opinion?  I don't feel strongly about it.

Ok.

>I'm going to leave it as is unless someone else suggests I should do

Ok.

>-19 so we can ensure we're on the same page before I upload it.  Let me know

Ok.

As an overall comment,l I'll leave the above open for one more 
day.  If nobody expresses an opinion I suggest choosing what seems 
reasonable to you.

Regards,