Subject: Re: [spfbis] New Version Notification - draft-ietf-spfbis-4408bis-18.txt

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

Hi Scott,
At 20:27 16-08-2013, [email-masked] wrote:
>A new version (-18) has been submitted for draft-ietf-spfbis-4408bis:
>http://www.ietf.org/internet-drafts/draft-ietf-spfbis-4408bis-18.txt

I see that the RFC 1983 is now informative.  There is still the following:

In Section 4.3:

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

And in Appendix A:

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

As you mentioned previously, the reference would be normative if it 
is referenced in the ABNF.  Could you change RFC 1983 to RFC 1035 in 
the above text?  The reason I am asking this is so that the question 
of whether RFC 1983 should be normative or not does not arise with 
the suggested change.

If you are okay with the above, please submit -19.

Thanks,
S. Moonesamy (as document shepherd)

---

From: Pete Resnick <[email-masked]>
Date: Fri, 16 Aug 2013 23:43:43 -0500

On 8/16/13 10:47 PM, S Moonesamy wrote:
> As you mentioned previously, the reference would be normative if it is 
> referenced in the ABNF.  Could you change RFC 1983 to RFC 1035 in the 
> above text?  The reason I am asking this is so that the question of 
> whether RFC 1983 should be normative or not does not arise with the 
> suggested change.
>

The problem is that 1035 never defines "fully qualified domain name". I 
think the definition in 4.3 is fine without making 1983 normative. But I 
also now think that putting 1983 in the ABNF is not so good: 1983 never 
gives the syntax for an FQDN; it only defines it.

So I say let's leave the (informative) reference to 1983 in 4.3. As far 
as the ABNF in appendix A, I don't see anywhere in the document that the 
ABNF terminal "domain" is used, so why is it there in the first place. 
Perhaps that ABNF definition can simply be removed.

BTW: While hunting through the document, I found an error in section 7.2:

<domain>, <sender>, and <ip> are defined in Section 2.2.

They are defined in 4.1. You should probably do a scrub of internal 
reference numbers before it gets to the RFC Editor.

pr

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

---

From: S Moonesamy <[email-masked]>
Date: Fri, 16 Aug 2013 22:12:28 -0700

Hi Pete,
At 21:43 16-08-2013, Pete Resnick wrote:
>The problem is that 1035 never defines "fully qualified domain 
>name". I think the

Yes.

>  definition in 4.3 is fine without making 1983 normative. But I 
> also now think that putting 1983 in the ABNF is not so good: 1983 
> never gives the syntax for an FQDN; it only defines it.

There isn't any ABNF in RFC 1983.  The BNF in RFC 1035 could be used 
but then your comment (see first line) applies.

>So I say let's leave the (informative) reference to 1983 in 4.3. As 
>far as the ABNF in appendix A, I don't see anywhere in the document 
>that the ABNF terminal "domain" is used, so why is it there in the 
>first place. Perhaps that ABNF definition can simply be removed.

I went through the draft-ietf-spfbis-4408bis-18 and I did not see a 
requirement for "domain".

>reference numbers before it gets to the RFC Editor.

Yes.

To summarize:

   (a) Fix the error in Section 7.2

   (b) Drop the "domain" line in the ABNF in Appendix A

If Scott and you are okay with that, a -19 can be generated and the 
Last Call initiated.

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 17 Aug 2013 01:13:31 -0400

> reference numbers before it gets to the RFC Editor.

I'm inferring from this I shouldn't submit -19?  Well clean it up later?

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 17 Aug 2013 01:26:26 -0400

> requirement for "domain".

As Pete mentioned, it's one of the inputs to check_host() listed in 4.1.  And 
is used many times as <domain> throughout the document.

> If Scott and you are okay with that, a -19 can be generated and the

No.  I'm not.  It's part of the ABNF introduced in 4.1 and properly part of 
the collected ABNF in Appendix A.  We did discuss this before which is how we 
got where we are not.  Removing it does not make sense to me and is contrary 
to the prior conclusion of the group.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Fri, 16 Aug 2013 22:59:25 -0700

Hi Scott,
>is used many times as <domain> throughout the document.

[snip]

>to the prior conclusion of the group.

Here's Section 4.1 from version -18:

    The check_host() function takes these arguments:

    <ip>     - the IP address of the SMTP client that is emitting the
               mail, either IPv4 or IPv6.

    <domain> - the domain that provides the sought-after authorization
               information; initially, the domain portion of the "MAIL
               FROM" or "HELO" identity.

    <sender> - the "MAIL FROM" or "HELO" identity.

    For recursive evaluations, the domain portion of <sender> might not
    be the same as the <domain> argument when check_host() is initially
    evaluated.  In most other cases it will be the same.  (See
    Section 5.2 below).

    Note that the <domain> argument might not be a well-formed domain
    name.  For example, if the reverse-path was null, then the EHLO/HELO
    domain is used, with its associated problems (see Section 2.3).  In
    these cases, check_host() is defined in Section 4.3 to return a
    "none" result.

I understand your (and Pete's) point about the input to check_host() 
listed in Section 4.1.  The possible issue is that there isn't any 
ABNF in Section 4.1.

According to RFC 1983:

   "The FQDN is the full name of a system, rather than just its hostname."

There isn't any ABNF in RFC 1983.

Regards,

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 17 Aug 2013 02:08:08 -0400

On Friday, August 16, 2013 22:59:25 S Moonesamy wrote:
> >As Pete mentioned, it's one of the inputs to check_host() listed in 4.1. 
> >And is used many times as <domain> throughout the document.
> 
> [snip]
> 
> >the collected ABNF in Appendix A.  We did discuss this before which is how
> >we got where we are not.  Removing it does not make sense to me and is
> >contrary to the prior conclusion of the group.
> 

That's true of many older RFCs.  IIRC that's the best reference for it we 
could come up with.

Scott K

---

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

Hi Pete,

Can the Last Call for draft-ietf-spfbis-4408bis-18 be initiated?

Thanks,

---

From: Pete Resnick <[email-masked]>
Date: Sat, 17 Aug 2013 07:54:48 -0500

On 8/17/13 12:26 AM, Scott Kitterman wrote:
> is used many times as<domain>  throughout the document.
>    

The *term* "domain" is used throughout the document, but it's never used 
as an ABNF terminal.

> to the prior conclusion of the group.

But this reasoning means that you have a different problem: There is no 
ABNF for "sender" or "ip". By your argument, those are missing and need 
to be added.

I don't think you need any of them. They are all described well enough 
in 4.1 and providing ABNF is unnecessary in my opinion.

But if the WG really thinks that providing ABNF for these is required, 
then a reference to 1983 (which provides no syntax) is not appropriate. 
I'd instead refer to 5321 definition of "Domain" for domain, the 5321 
definition of "Mailbox" for sender, and simply create the ABNF for ip.

BTW: In 1.1.2, you incorrectly identify "local-part" as imported from 
5321. That's wrong. 5321 has "Local-part". Easy enough to fix that. I'm 
not worried about the rest of the references to it throughout the 
document as lowercase "local-part"; 5321 does that too.

So, here would be my list of changes to accomplish this:

- In 1.1.2, change the second sentence to: "The tokens "Local-part", 
"Domain", and "Mailbox" are defined in [RFC5321]."
- Remove "domain" from Appendix A; it's now imported from 5321.
- Add "sender = Mailbox" to Appendix A
- Add "ip = ip4-network / ip6-network" to Appendix A

pr

---

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

On Saturday, August 17, 2013 07:54:48 Pete Resnick wrote:
> > And is used many times as<domain>  throughout the document.
> 

All done locally for -19.

Scott K