Subject: [spfbis] References in draft-ietf-spfbis-4408bis-01

From: SM <[email-masked]>
Date: Wed, 27 Jun 2012 23:23:34 -0700

Hello,

Here's a few nits about the references in 
draft-ietf-spfbis-4408bis-01.  The reference to
RFC 4409 should be changed to RFC 6409.  RFC 2440 should be changed 
to RFC 4880.  RFC 2554 should be changed to RFC 4954.  RFC 3851 
should be changed to RFC 5751.

The reference to RFC 3696 may have to be changed.  This will have to 
be a normative reference.  How do existing implementations handle the 
restriction for TLDs in Section 8.1?

Regards,
-sm

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 28 Jun 2012 12:32:52 -0400

> should be changed to RFC 5751.

I've been working through the nits page for the latest draft.  I'm trying to 
address all the reference and ABNF nits (added a section on imported 
definitions.  These are all fixed.

Nits also whines about possible downref to US-ASCII.  Can I assume that 
complaint is safe to ignore?

> restriction for TLDs in Section 8.1?

For pyspf, the implemented test is fairly basic.  The TLD can't be all numeric 
or start/end with a hyphen.  

I think 3696 is informational.  I looked at some other related RFCs.  The 
current DKIM RFC points at 5321 for domain name and it says:

Domain         = sub-domain *("." sub-domain)
sub-domain     = Let-dig [Ldh-str]

Given that the underlying email protocol we're building on doesn't specify 
special treatment for TLD naming, I think that the reference to 3696 is a 
helpful hint for implementors that may want to get local efficiencies.  
Reference to it isn't essential for interoperability.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Thu, 28 Jun 2012 10:18:03 -0700

Hi Scott,
>definitions.  These are all fixed.

Thanks.

>complaint is safe to ignore?

Yes, the US-ACII reference is correct.

>I think 3696 is informational.  I looked at some other related RFCs.  The

RFC 3696 is not an IETF RFC.

>sub-domain     = Let-dig [Ldh-str]

Some specifications use that.

>Reference to it isn't essential for interoperability.

Appendix A is normative.  RFC 4408 has the following for the TLD:

    toplabel         = ( *alphanum ALPHA *alphanum ) /
                       ( 1*alphanum "-" *( alphanum / "-" ) alphanum )
                       ; LDH rule plus additional TLD restrictions
                       ; (see [RFC3696], Section 2)

The implementation of the the specification has to parse "toplabel" 
for syntax with the above and the additional TLD restrictions.

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 28 Jun 2012 14:11:17 -0400

On Thursday, June 28, 2012 10:18:03 AM S Moonesamy wrote:
> >I've been working through the nits page for the latest draft.  I'm trying
> >to address all the reference and ABNF nits (added a section on imported

The operative bit of Section 2 is:

   The LDH rule, as updated, provides that the labels (words or strings
   separated by periods) that make up a domain name must consist of only
   the ASCII [ASCII] alphabetic and numeric characters, plus the hyphen.
   No other symbols or punctuation characters are permitted, nor is
   blank space.  If the hyphen is used, it is not permitted to appear at
   either the beginning or end of a label.  There is an additional rule
   that essentially requires that top-level domain names not be all-
   numeric.

Which is, If I read it correctly, what the toplabel ABNF definition already 
tells you.  RFC3696 has additional information and context for the definition, 
but it's not required for implementation.  The current text may be a bit 
confusing because it could be read to mean consult 3696 for additional 
restrictions, but the additional restrictions are already in the ABNF.  
Perhaps it would be clearer if we changed the comment to:

                        ; LDH rule plus additional TLD restrictions
                        ; (see [RFC3696], Section 2 for background
                        ; information)

Is there some information in 3696 that isn't in 4408 that an implementer 
needs?

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 28 Jun 2012 11:19:44 -0700

> RFC 3696 is not an IETF RFC.

Sorry; can you elaborate?  I don't know what "not an IETF RFC" means.

> Some specifications use that.

I think we'd be quite safe re-using that, and keeping it simple.

-MSK

---

From: Barry Leiba <[email-masked]>
Date: Thu, 28 Jun 2012 14:23:39 -0400

> Sorry; can you elaborate?  I don't know what "not an IETF RFC" means.

He means that it's not published in the IETF Stream (today it's marked
as in the Independent Stream, which didn't exist at the time).

Barry

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 28 Jun 2012 11:28:59 -0700

> as in the Independent Stream, which didn't exist at the time).

That still makes it an Informative reference, though, correct?

That is, I don't see how it's an important distinction in this context.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 28 Jun 2012 14:38:09 -0400

> I think we'd be quite safe re-using that, and keeping it simple.

Does that change the design?

Domain         = sub-domain *("." sub-domain)
sub-domain     = Let-dig [Ldh-str]
Let-dig        = ALPHA / DIGIT
Ldh-str        = *( ALPHA / DIGIT / "-" ) Let-dig

My naive reading of that (ABNF is not really my thing) is that's different than 
what's in RFC 4408:

alphanum         = ALPHA / DIGIT

I don't think we should change definitions because the definition that was used 
before is in an inconvenient place.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 28 Jun 2012 11:58:59 -0700

> before is in an inconvenient place.
Since the latter is in RFC4408, I'm not clear on what you mean by
"inconvenient place".  It's certainly simple enough to make reference to
external ABNFs.

What I don't understand is the need for the complexity of what's in RFC4408.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 28 Jun 2012 15:08:14 -0400

On Thursday, June 28, 2012 11:58:59 AM Murray S. Kucherawy wrote:
> > > On Thu, Jun 28, 2012 at 10:18 AM, S Moonesamy <[email-masked]>
> > 
> > wrote:
> > > > I think 3696 is informational.  I looked at some other related RFCs.
> >  
> >  The
> >  

That was a reference to the discussion about if we could reference 3696.

> What I don't understand is the need for the complexity of what's in RFC4408.

I don't recall precisely, but I believe it was intended to exclude address 
literals.  In retrospect we probably could have not worried about it and 
combined ip4/ip6/a into a single mechanism, but that's not the design we've 
got.

I'm not aware of the current ABNF causing any problems, so I think it ought to 
stay as it is.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Thu, 28 Jun 2012 13:13:06 -0700

Hi Scott,
>tells you.  RFC3696 has additional information and context for the 

Now I see what you mean.  You are referring to that section for the 
LDH rule and the additional rule.  In general that's RFC 952 with the 
RFC 1123 update.  Murray Kucherawy commented on using the ABNF from 
RFC 5321.  That's another way to tackle the issue.

>Is there some information in 3696 that isn't in 4408 that an implementer

That is a question for working group participants to address.

You turned the RFC 3696 reference into an informative one.  :-)  The 
ABNF mentions "LDH rule plus additional TLD restrictions".  An 
"external" reviewer would ask where to find the additional TLD restrictions.

We would also be changing the ABNF.  Given that the ABNF is normative 
in this draft I consider such a change as substantive.  I would like 
to get more input on this from other WG participants.

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: S Moonesamy <[email-masked]>
Date: Thu, 28 Jun 2012 12:26:06 -0700

Hi Murray,
>That still makes it an Informative reference, though, correct?

The RFC can be used as a reference.  According to my reading of the 
draft it would have to be normative.

>That is, I don't see how it's an important distinction in this context.

I am looking at this as a specification which explains what is 
expected of the syntax parser.  I'll elaborate with an 
example.  Let's say that X is a "string" which is a valid domain 
name.  We all know what a domain name is.  If we write code, we have 
to figure out what is actually a domain name.  Is there any limit on 
the number of octets for the "string"?  Is there any octet limit for 
(DNS) labels?  What about LDH?  If there is a normative reference to 
RFC 1035, we look at that specification to find the answers.  That 
RFC does not provide all the details about "TLD restrictions".  Now 
we have to go and find a specification to derive the "rules" for 
that.  Which specification can we use?  Would the IETF consider the 
reference as a good one?

I cannot say: "this is a RFC; it is good enough".  Did I do any 
research to see whether there is a RFC published in the IETF Stream 
which is considered as authoritative on that subject?  This is where 
AD tells me that I wasn't diligent in reviewing the work before 
requesting the AD review.

This is also about "did you think about it" so that you don't have to 
be the deer in the headlights when the issue is raised.

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 28 Jun 2012 16:52:06 -0400

> to get more input on this from other WG participants.

No.  I didn't.  It's already an informative one.  All I'm saying is that 4408 
is correct and there's no reference deficiency to correct.  If we need to 
clarify the comment to make that more clear, I don't think that actually 
changes anything.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 29 Jun 2012 13:32:20 +0200

> to get more input on this from other WG participants.

I'd avoid to change the ABNF unless we find errors in it.  In that
respect, moving a reference is less of a change than adding a comment.

jm2c

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 29 Jun 2012 08:02:54 -0400

>respect, moving a reference is less of a change than adding a comment.

My suggestion was neither of those. There's already an informational comment. My preference is to leave it unchanged, but if people find the comment confusing we should clarify it (by which I mean make clear the original meaning).

Scott K