Subject: [spfbis] Adding a note in Section 4.8 of draft-ietf-spfbis-4408bis

From: S Moonesamy <[email-masked]>
Date: Thu, 03 Apr 2014 14:17:49 -0700

Hello,

The following note is being added at the end of Section 4.8 of 
draft-ietf-spfbis-4408bis (see RFC 4408 Errata for history):

   'Note: Historically, this document has made no provisions for how to
    handle <domain-spec>s, or macro-expansions thereof, that are
    syntactically invalid per [RFC1035], such as names with empty labels
    (e.g., "foo..example.com") or overlong labels (more than
    63 characters).  For mechanisms, some implementations treat such
    names as not-match and for modifiers silently ignore them, while
    other implementations will throw a "permerror" in this case.  The
    outcome for an unexpected <domain-spec> without macros might even
    differ from that for an unexpected <target-name> after macro
    expansion.'

I'll assume that the working group is okay with this change if nobody 
speaks up.

Regards,
S. Moonesamy (as document shepherd)

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 04 Apr 2014 10:47:41 +0200

Hi,

> I'll assume that the working group is okay with this change if nobody

I agree on adding a note.  However, I don't agree with the wording
proposed in the Errata, reported to the list on February 22, 2012:
http://www.ietf.org/mail-archive/web/spfbis/current/msg00476.html

That wording was discussed on this list.  Dave and Scott came up with
a better version on May 8, 2013:

   Note:  This document and its predecessors make no provisions for
   defining correct handling of syntactically invalid domain-specs or
   macro-expansion, per <xref target="RFC1035"/>.  Examples include
   names with empty labels, such as "foo..example.com", and labels
   that are longer than 63 characters.  Some implementations choose
   to treat such errors as no-match and therefore ignore such names,
   while others return a "permerror" exception.

   http://www.ietf.org/mail-archive/web/spfbis/current/msg03699.html
   (s/at no-match/as no-match/)

Ale

---

From: S Moonesamy <[email-masked]>
Date: Sat, 05 Apr 2014 09:13:35 -0700

Hi Alessandro,
>    (s/at no-match/as no-match/)

Thanks for suggesting text.  The document currently uses 
"<domain-spec>" and "macro expansion", hence the following editorial changes:

    Note:  This document and its predecessors make no provisions for
    defining correct handling of a syntactically invalid <domain-spec>
    or macro expansion, per <xref target="RFC1035"/>.  Examples include
    names with empty labels, such as "foo..example.com", and labels
    that are longer than 63 characters.  Some implementations choose
    to treat such errors as no-match and therefore ignore such names,
    while others return a "permerror" exception.

Regards,

---

From: S Moonesamy <[email-masked]>
Date: Mon, 07 Apr 2014 12:22:37 -0700

Hello,
>    while others return a "permerror" exception.

Scott Kitterman and Andrew (as SPFBIS WG Chair) are okay with the 
above text.  If there aren't any objections by Wednesday, April 9th 
I'll ask the RFC Editor to make the change.

Regards,

---

From: Douglas Otis <[email-masked]>
Date: Wed, 9 Apr 2014 11:28:54 -0700

Dear SM,

One objection to such inclusion is the implication by including macros is that they are actually supported and not often ignored.  A simple statement that macros in general are not handled consistently would be preferable.

Regards,
Douglas Otis

On Apr 7, 2014, at 12:22 PM, S Moonesamy <[email-masked]> wrote:

> Scott Kitterman and Andrew (as SPFBIS WG Chair) are okay with the above text.  If there aren't any objections by Wednesday, April 9th I'll ask the RFC Editor to make the change.
> 
> Regards,
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 09 Apr 2014 15:02:23 -0400

It doesn't imply that any more than including macros in the document does.  
We've already had that discussion and are well past it.  This isn't an open 
door to re-litigate things the working group has already discussed.

Scott K

On Wednesday, April 09, 2014 11:28:54 Douglas Otis wrote:
> Dear SM,
> 
> One objection to such inclusion is the implication by including macros is
> that they are actually supported and not often ignored.  A simple statement
> that macros in general are not handled consistently would be preferable.
> 
> Regards,
> Douglas Otis
> 
> > Scott Kitterman and Andrew (as SPFBIS WG Chair) are okay with the above
> > text.  If there aren't any objections by Wednesday, April 9th I'll ask
> > the RFC Editor to make the change.
> > 
> > Regards,

---

From: Douglas Otis <[email-masked]>
Date: Wed, 9 Apr 2014 12:06:46 -0700

Dear Scott,

Please consider this a matter of not providing deceptive or unhelpful information.

Regards,
Douglas Otis

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 09 Apr 2014 15:08:58 -0400

It's not.  (now you can reply "It is" and this can go on all day)

You're view on macros is well known and well established.  It's not the one 
that the working group supported.  Within the established consensus of the 
working group, I think the note is reasonable.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Wed, 09 Apr 2014 12:27:12 -0700

Hi Douglas,
>Please consider this a matter of not providing deceptive or 

In the message at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg04274.html it 
is mentioned that:

   "A simple statement that macros in general are not handled consistently
    would be preferable."

The suggested note has the following:

   "This document and its predecessors make no provisions for
    defining correct handling of a syntactically invalid <domain-spec>
    or macro expansion,"

The two (quoted) text seem similar to me.  The second sentence of the 
suggested note ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg04273.html ) 
provides examples.  The last sentence is about what some 
implementations do and what other implementations do.

I did not find anything deceptive in the suggested text.  I may be 
reading the suggested text incorrectly.  I would like other working 
group participants to comment as it would help to figure out how to 
resolve this last issue.

Thanks,

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 9 Apr 2014 17:44:47 -0400

Hi Doug,

I think your objection is just shy of completely irrelevant to the
question at hand.  The question at hand is about a note involving
syntactically invalid <domain-spec> and macro expansions.

You are right that, to the extent macros cause problems, they will
cause problems.  But that's not the issue in this text; instead, it's
about cases of syntactic _invalidity_. 

I have no objection to modifying the text this way:

    Note: This document and its predecessors make no provisions for
    defining correct handling of a syntactically invalid <domain-spec>
    (or macro expansion that results in such syntactic invalidity),
    per <xref target="RFC1035"/>.

Would that help?  The WG decided with a pretty strong consensus that
macros were not going to be removed.  Given that they're not going to
be removed, the proposed text is merely to deal with a particular case
involving bad deployments.  You cannot sneak in another objection to
macros in general here: the WG has already decided on that point.  The
question is only whether, _given that_ macros are included, you can
live with the proposed text (or the elaboration above, if you prefer).

Best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Wed, 9 Apr 2014 15:14:56 -0700

> live with the proposed text (or the elaboration above, if you prefer).

Dear Andrew,

The intent was not to "sneak" in another objection.  The intent was to offer well considered advice.

Inclusion of macros in this concern is likely deceptive.  This advice does not represent a meaningful correction to current macro handling.  A general statement that attempts to extend a syntax correction could do so by simply stating macros are not handled consistently and leave it at that.  This would avoid offering any allusion that this errata offers in any way a meaningful correction to how macros are currently used.  It does not (thankfully).

Regards,
Douglas Otis

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 9 Apr 2014 18:31:33 -0400

Doug,

On Wed, Apr 09, 2014 at 03:14:56PM -0700, Douglas Otis wrote:
> The intent was to offer well considered advice.

You neatly avoided responding to my proposed text alteration, or
suggesting different text.  Do you just want to leave macros out of
the text at all?  Can you please either suggest altered text, or say
that you object to the inclusion absolutely?

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 09 Apr 2014 18:48:11 -0400

I think the proposed change makes the note substantially less useful. The original text resolves a specific ambiguity with specifics about where the ambiguity lies.  This proposed change abstracts away the useful information for people that aren't DNS experts. 

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Wed, 9 Apr 2014 15:50:42 -0700

Dear Andrew,

Your modified text missed the concern.

Note:  This document and its predecessors make no provisions for defining correct handling of syntactically invalid <domain-spec> per <xref target="RFC1035"/>.  Syntax related examples include names with empty labels, such as "foo..example.com", and labels that are longer than 63 characters.  Some implementations choose to treat such errors as no-match and therefore ignore such names, while others return a "permerror" exception.  Macro expansion might be handled in a similar fashion irrespective of any related syntax issues.

Regards,
Douglas Otis

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 09 Apr 2014 18:52:02 -0400

On April 9, 2014 6:48:11 PM EDT, Scott Kitterman <[email-masked]> wrote:
>I think the proposed change makes the note substantially less useful.
>The original text resolves a specific ambiguity with specifics about
>where the ambiguity lies.  This proposed change abstracts away the
>useful information for people that aren't DNS experts. 
>
>Scott K
>

Sorry. That was meant to be a reply to Andrew's proposed change.

Scott K

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 9 Apr 2014 18:55:46 -0400

Ok, thanks.

What about Doug's latest?  

I think the _point_ is that, if a <domain-spec> is syntactically
invalid, then it's undefined what happens and we know that, right?
And this is true even if the <domain-spec> results from macro
processing, correct?

A

-- 
Andrew Sullivan
[email-masked]

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 09 Apr 2014 19:00:07 -0400

On April 9, 2014 6:50:42 PM EDT, Douglas Otis <[email-masked]> wrote:
>defining correct handling of syntactically invalid <domain-spec> per
><xref target="RFC1035"/>.  Syntax related examples include names with
>empty labels, such as "foo..example.com", and labels that are longer
>than 63 characters.  Some implementations choose to treat such errors
>as no-match and therefore ignore such names, while others return a
>"permerror" exception.  Macro expansion might be handled in a similar
>fashion irrespective of any related syntax issues.
>
>Regards,
>Douglas Otis
>
>

Absolutely not. 

The note is about resolving an ambiguity in the spec.  Not a generic warning that macros suck.

Deliberately or not your responses are orthogonal to the question at hand.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 09 Apr 2014 19:12:06 -0400

>What about Doug's latest?  

Replied separately. 

>And this is true even if the <domain-spec> results from macro

Yes.   The most likely scenario for that is a macro expanding to nothing resulting in consecutive dots or an empty domain-spec.  That's why I like the note in it's longer form.

Scott K

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Fri, 11 Apr 2014 12:41:14 -0700

Hello,

I'll try to summarize the discussion about the note in Section 4.8 of 
draft-ietf-spfbis-4408bis.

Andrew Sillivan asked whether "the _point_ is that, if a 
<domain-spec> is syntactically
invalid, then it's undefined what happens and we know that, right? 
And this is true even if the <domain-spec> results from macro 
processing, correct?" [1] and Scott Kitterman agreed to that [2].  He 
also mentioned that "the most likely scenario for that is a macro 
expanding to nothing resulting in consecutive dots or an empty domain-spec".

Douglas Otis suggested the following additional text to address his 
concern [3]:

   "Macro expansion might be handled in a similar fashion irrespective of any
    related syntax issues."

Scott Kitterman read the above text as "a generic warning that macros 
suck" [4].  As a reminder the objection from Douglas Otis was [5]:

   "the implication by including macros is that they are actually supported and
    not often ignored."

I'll comment as from here.  How about:

   "Note:  This document and its predecessors make no provisions for
    defining correct handling of a syntactically invalid <domain-spec>,
    per <xref target="RFC1035"/>.  Examples include names with empty
    labels, such as "foo..example.com", and labels that are longer than
    63 characters.  Some implementations choose to treat such errors as
    no-match and therefore ignore such names, while others return a
    "permerror" exception."

Regards,

1. http://www.ietf.org/mail-archive/web/spfbis/current/msg04285.html
2. http://www.ietf.org/mail-archive/web/spfbis/current/msg04287.html
3. http://www.ietf.org/mail-archive/web/spfbis/current/msg04283.html
4. http://www.ietf.org/mail-archive/web/spfbis/current/msg04286.html
5. http://www.ietf.org/mail-archive/web/spfbis/current/msg04274.html
6. http://www.ietf.org/mail-archive/web/spfbis/current/msg04272.html

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 11 Apr 2014 19:16:41 -0400

On Friday, April 11, 2014 12:41:14 S Moonesamy wrote:
>    "Macro expansion might be handled in a similar fashion irrespective of
> any related syntax issues."
> 
>    "the implication by including macros is that they are actually supported
> and not often ignored."
> 

Works for me.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Fri, 11 Apr 2014 16:40:03 -0700

Hi Douglas,
At 11:28 09-04-2014, Douglas Otis wrote:
>One objection to such inclusion is the implication by including 
>macros is that they are actually supported and not often ignored.  A 
>simple statement that macros in general are not handled consistently 
>would be preferable.

I posted a rough summary of the discussion at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg04288.html and 
suggested some text for the note.  Could you please review that 
message and the suggested text to see whether it addresses the above 
objection?  It would help if I could get a response by Monday 14th April.

Thanks,

---

From: Douglas Otis <[email-masked]>
Date: Sat, 12 Apr 2014 23:18:10 -0700

Dear SM,

Your wording is an improvement.

Regards,
Douglas Otis

On Apr 11, 2014, at 4:40 PM, S Moonesamy <[email-masked]> wrote:

> I posted a rough summary of the discussion at http://www.ietf.org/mail-archive/web/spfbis/current/msg04288.html and suggested some text for the note.  Could you please review that message and the suggested text to see whether it addresses the above objection?  It would help if I could get a response by Monday 14th April.
> 
> Thanks,

---

From: S Moonesamy <[email-masked]>
Date: Thu, 17 Apr 2014 11:15:59 -0700

Hi Douglas,
>Your wording is an improvement.

Thanks for the reply.  I apologize for being slow with the follow-up.

I discussed the suggested note with Andrew (as WG Chair) and we 
concluded that the following text fits better with the rest of the 
text in Section 4.8:

   "Note: This document and its predecessors make no provisions for
    defining correct handling of a syntactically invalid <domain-spec>
    (which might be the result of macro expansion), per <xref 
target="RFC1035"/>.
    Examples include names with empty labels, such as "foo..example.com",
    and labels that are longer than 63 characters.  Some implementations
    choose to treat such errors as no-match and therefore ignore such
    names, while others return a "permerror" exception."

Given the existence of macros, do you object here to warning about 
their side effects?

Regards,

---

From: Douglas Otis <[email-masked]>
Date: Fri, 18 Apr 2014 09:11:44 -0700

On Apr 17, 2014, at 11:15 AM, S Moonesamy <[email-masked]> wrote:

> I discussed the suggested note with Andrew (as WG Chair) and we concluded that the following text fits better with the rest of the text in Section 4.8:
> 
>   (which might be the result of macro expansion), per <xref target="RFC1035"/>.
> Given the existence of macros, do you object here to warning about their side effects?

Dear SM,

I doubt we'll ever reach a point where this group accepts many don't expand SPF macros and this part of the protocol is seriously broken and seldom used (a good thing).   You have turned that around a bit.  Nevertheless this wording is still an improvement.  Thank you.

Regards,
Douglas Otis

---

From: S Moonesamy <[email-masked]>
Date: Fri, 18 Apr 2014 09:33:11 -0700

Hi Douglas,
At 09:11 18-04-2014, Douglas Otis wrote:
>I doubt we'll ever reach a point where this group accepts many don't 
>expand SPF macros and this part of the protocol is seriously broken 
>and seldom used (a good thing).   You have turned that around a 
>bit.  Nevertheless this wording is still an improvement.  Thank you.

Thanks for understanding the various opinions.  I'll consider the 
objection at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg04274.html as 
addressed.  I'll ask the RFC Editor to add the note to Section 4.8 of 
draft-ietf-spfbis-4408bis.

Regards,

---

From: S Moonesamy <[email-masked]>
Date: Sat, 19 Apr 2014 16:22:36 -0700

Hello,

There was a mistake in the suggested text for the note.  The correct text is:

    Note: This document and its predecessors make no provisions for
    defining correct handling of a syntactically invalid <domain-spec>
    (which might be the result of macro expansion), per [RFC1035].
    Examples include names with empty labels, such as "foo..example.com",
    and labels that are longer than 63 characters.  Some implementations
    choose to treat such errors as not-match and therefore ignore such
    names, while others return a "permerror" exception.

The change is "not-match" in the last sentence.

Regards,