Subject: [spfbis] Draft document shepherd Write-Up for draft-ietf-spfbis-4408bis-16

From: S Moonesamy <[email-masked]>
Date: Fri, 12 Jul 2013 14:11:22 -0700

Hello,

This is a draft of the Document Shepherd Write-Up.  Please let me 
know if I missed anything important.  I added a comment in (10) about 
extreme discontent during the WGLC.  Please email me off-list if you 
are of the opinion that there is an issue which has not been 
addressed correctly.

(1) The type of RFC being requested is Proposed Standard.  The draft describes
     version 1 of the Sender Policy Framework (SPF) protocol, whereby an
     Administrative Management Domain can explicitly authorize the  hosts
     that are allowed to use its domain names, and a receiving host can check
     such authorization.  The type is indicated in the title page header.

(2) The approval announcement contains the following sections:

Technical Summary

   This document describes version 1 ofthe Sender Policy Framework
   (SPF) protocol, whereby an Administrative Management Domain can
   explicitly authorize the hosts that are allowed to use its
   domain names, and a receiving host can check such authorization.

Working Group Summary

   The decision about whether the SPF protocol has to reject mail or not
   when the result of the evaluation is "Fail" was controversial.  There
   was WG consensus not to standardize SPF Best-guess processing.

   The issue of mail forwarding and mailing lists in respect to the SPF
   protocol was not too controversial in comparison with the other
   controversies.  There was some controversy about whether the use of
   macros was a security risk and whether to deprecate the PTR feature.

   There was a formal appeal of the SPFBIS WG chair' interpretation of the
   charter, specifically regarding the removal of "unused" features.  The
   two features in particular which drove the appeal were the PTR feature
   and the local-part macro feature.  These features were not removed from the
   document given that the appeal was denied by the Responsible Area Director.

   There was significant discussion about whether to use the "Received-SPF:"
   header field or whether to use the "Authentication-Results" header field
   to record the results of a SPF evaluation.  The working group decided to
   add both header fields in the document as they are in common use.

   There was a suggestion to reorganize the document.  It was argued that the
   document had become somewhat bloated with documentation of nuance and other
   text that has nothing to do with defining a protocol and enabling
   interoperability.  This led to a stalemate.  Based on the discussion during
   the SFPBIS WG session at IETF 85 the WG decided to proceed with a
   reorganization of the document while ensuring that the reorganization did
   not create any text changes apart from moving text around.

   The topic of obsoleting the SPF RRTYPE generated a lot of controversy near
   the end of the WGLC.  There was an intermediate conclusion about the topic
   before the WGLC and it was followed by an objection.  After the discussion
   of the topic at the IETF 83 SPFBIS WG session the conclusion reached was
   that the decision would be not to publish RRTYPE 99 and and not to query
   RRTYPE 99.  The WG consensus about the RRTYPE can be described as
   particularly rough.  There were a very high number of messages about the
   topic on the SPFBIS mailing list and the DNSEXT mailing list as the
   DNSEXT WG participants were not aware of RFC 6686.

Document Quality

   There are multiple existing implementations of the SPF protocol.  The
   document was reviewed by the SPFBIS working group.  Dave Crocker,
   Cyrus Daboo, Stuart Gathman, Murray Kucherawy, John Levine,
   Andrew Sullivan, Arthur Thisell, and Alessandro Vesely reviewed the
   document.  Simon Perreault helped to clarify the meaning of
   IPv4 mapped IPv6 addresses.  Murray Kucherawy deserves a special
   mention for his contributions.

Personnel

   S. Moonesamy is the Document Shepherd for this document. Pete Resnick
   is the Responsible Area Director.

(3) I have personally reviewed draft-ietf-spfbis-4408bis-16.  I believe that
     the draft is reading for forwarding to the IESG for publication.

(4) This document has been reviewed by several SPFBIS WG participants.
     The document has also been reviewed by Andrew Sullivan. I do not have
     any concerns about the depth and breath of the reviews performed.

(5) The document was reviewed by Cyrus Daboo on behalf of the Applications
     Area Directorate.  Simon Perreault reviewed the IPv6-related text in
     Section 5.  I suggest further review of the document from a DNS
     perspective.

(6) I do not have any specific concerns or issues with the document.

(7) The author confirmed that any and all appropriate IPR disclosures
     required for full conformance with the provisions of BCP 78 and
     BCP 79 have already been filed.

(8) There are no IPR disclosures referencing this document.

(9)  There is rough consensus within the WG to publish the document.
      The decision to obsolete the SPF RRTYPE was very controversial.

(10) Nobody has threatened an appeal during the WGLC.  Some WG
      participants have mentioned that they may express extreme
      discontent during the Last Call.

(11) Id-nits lists a non-RFC2606-compliant FQDN, six non-RFC5735-compliant
      IPv4 addresses and one instance of a private range IPv4 address.
      These warnings can be ignored.  The warning about CFWS is incorrect.
      The reference to RFC 2671 is intentional;  the document also
      references RFC 6891.

(12) The document does not require any formal review.

(13) All references within this document been identified as either
      normative or informative.

(14) The document normatively references RFCs.

(15) There is a downward reference to RFC 5598.

(16) The publication of this document changes the status of RCC 4408
      to obsolete.

(17) IANA action is requested to update the Resource Record (RR)
      TYPEs registry.  The "Received-SPF:" header field is
      being added to the Permanent Message Header Field Registry.
      Action is requested to update the SPF Modifier Registry.

(18) The document does not create any IANA registries.

(19) An automated check of the ABNF in Appendix A was performed.

Regards,
S. Moonesamy

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 12 Jul 2013 22:10:12 -0700

On Fri, Jul 12, 2013 at 2:11 PM, S Moonesamy <[email-masked]> wrote:

> Hello,
>
> This is a draft of the Document Shepherd Write-Up.  Please let me know if
> I missed anything important.  I added a comment in (10) about extreme
> discontent during the WGLC.  Please email me off-list if you are of the
> opinion that there is an issue which has not been addressed correctly.
>

There's a simplified shepherd write-up that the Applications Area ADs are
asking us to use.  I'll post a link to it later this evening if you can't
find it yourself, but I think it's on the Applications Area wiki.

>     such authorization.  The type is indicated in the title page header.

Shouldn't this also mention the status and history of RFC4408 in a sentence
or two?

>   This document describes version 1 ofthe Sender Policy Framework

s/ofthe/of the/

>      The decision to obsolete the SPF RRTYPE was very controversial.

You mentioned that already.

> (19) An automated check of the ABNF in Appendix A was performed.
Based on this, Jari may complain that the ABNF checking was not more
thorough.  I would also add that the reviewers checked the ABNF.

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Fri, 12 Jul 2013 23:22:17 -0700

Hi Murray,
At 22:10 12-07-2013, Murray S. Kucherawy wrote:
>There's a simplified shepherd write-up that the Applications Area 
>ADs are asking us to use.  I'll post a link to it later this evening 
>if you can't find it yourself, but I think it's on the Applications Area wiki.

I'll try and fit the answers in the new write-up template.

>Shouldn't this also mention the status and history of RFC4408 in a 
>sentence or two?

The answer to (1) is to say why the intended status is Proposed Standard.

>   This document describes version 1 ofthe Sender Policy Framework

Thanks for catching this.

>thorough.  I would also add that the reviewers checked the ABNF.

It is up to the document shepherd to do the verification. :-)

The ABNF checker flagged "authserv-id" "reasonspec", among others, as 
not used.  I could not find any reference to them in the 
draft.  Could you double-check that?

Regards,
S. Moonesamy

---

From: Måns Nilsson <[email-masked]>
Date: Sat, 13 Jul 2013 08:35:04 +0200

> This is a draft of the Document Shepherd Write-Up.  Please let me

<snip>

>   DNSEXT WG participants were not aware of RFC 6686.

The DNSEXT participants have read, understood and dismissed 6686 as obsolete and incomplete.  

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Now I'm having INSIPID THOUGHTS about the beatiful, round wives of
HOLLYWOOD MOVIE MOGULS encased in PLEXIGLASS CARS and being approached
by SMALL BOYS selling FRUIT ...

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 13 Jul 2013 00:23:09 -0700

On Fri, Jul 12, 2013 at 11:22 PM, S Moonesamy <[email-masked]> wrote:

>
> The ABNF checker flagged "authserv-id" "reasonspec", among others, as not
> used.  I could not find any reference to them in the draft.  Could you
> double-check that?
>
>
They can be removed.  Scott can confirm, but I think they were present in
an example that has since been removed.

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Sat, 13 Jul 2013 00:39:04 -0700

At 00:23 13-07-2013, Murray S. Kucherawy wrote:
>They can be removed.  Scott can confirm, but I think they were 
>present in an example that has since been removed.

Murray, thanks.

Scott, could you please review the message at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03860.html and 
submit a revision of the draft?  Please note that the cut-off for I-D 
submission is July 15 at 24:00 UTC.

I'll send the publication request to the Responsible Area Director 
once the new version of the draft is available.

Regards,
S. Moonesamy (as document shepherd)

---

From: Barry Leiba <[email-masked]>
Date: Sat, 13 Jul 2013 14:36:50 -0400

> I'll try and fit the answers in the new write-up template.

Yes, please, unless Pete has specifically told you he prefers this one.

(1) The type of RFC being requested is Proposed Standard.  The draft
>> describes

Yes, and a key reason is that this is specifically intended to bring the
experimental RFC 4408 to Standards Track.  I think most ADs know that, but
that is key information for them to know.  So yes, Murray is right.

Barry

---

From: Hector Santos <[email-masked]>
Date: Sun, 14 Jul 2013 12:11:00 -0400

>    was WG consensus not to standardize SPF Best-guess processing.

I don't think you intended to do this, but these are two different 
concepts.  The way you have it can provide the erroneous implication 
that the SPF FAIL message rejection operations are some form of 
subjective "best-guessing" process.

You need to clearly separate them and point out that Best-Guess is an 
independent concept outside the SPF protocol process, completely 
unrelated to actionable deterministic SPF FAIL policy.   I think it is 
important to note that SPF FAIL rejection policies was the dominant 
inclination when it was invented, written early into the draft 
specifications and RFC 4408 documentation and that it is only a 
reflection of some modern deployments that DO NOT honor the policy, in 
the name of depending on user-based policies, hence the new highlights 
in the security concerns.

>    not create any text changes apart from moving text around.

Which I do not believe was fully achieved.  Any current deployment who 
reads this doc will need to ignore it if he doesn't wish to impose 
change work for his SPF operation.

>    DNSEXT WG participants were not aware of RFC 6686.

It should be noted that this was a long time understood design and 
development issue and the migration path initially envisioned was on par 
with what has occurred in the market albeit slow.   A note should be 
stated with how TXT based solution is more acceptable today than 
yester-years, hence why its allowed to be used.

>    mention for his contributions.

There are a lot of folks who contributed to this, even if it was done 
with resistance.  No one here acts by him/her-self. Synergism is in effect.

> (16) The publication of this document changes the status of RCC 4408

I believe the draft is updated enough to warrant TWO different 
declarations of supports; RFC4408 level only or this new RFC4408BIS 
level of support.  So until current 4408 implementations are ready to 
begin supporting all or some of the new changes in BIS, RFC4408 will not 
be "obsolete" to them.

For me, this 4408BIS is not an easy PLUG AND PLAY update to 4408. For 
example, one can stay with 4408 and remain compliant, and make the CLAIM 
he is compliant without adding AUTH-RES and REJECTING with FAIL.  The 
don't have to worry about the security concerns of attempted to accept 
SPF failed mail in the name of using AUTH-RES results and crossing 
fingers, post-processing components will negatively classify the SPF 
FAILed-by-policy message.

In short, I don't think this document is ready for any future "Internet 
Standard" promotion declaration without additional changes.

--
HLS

---

From: S Moonesamy <[email-masked]>
Date: Sun, 14 Jul 2013 15:33:48 -0700

>The DNSEXT participants have read, understood and dismissed 6686 as 

Ok.

The text I wrote says is based on comments I saw in the SPFBIS 
mailing list archive.

>Yes, please, unless Pete has specifically told you he prefers this one.

I'll use the new write-up.

>Yes, and a key reason is that this is specifically intended to bring 
>the experimental RFC 4408 to Standards Track.  I think most ADs know 
>that, but that is key information for them to know.  So yes, Murray is right.

I'll add that.

>subjective "best-guessing" process.

Ok.  I read the text again and I see that it can be 
misinterpreted.  I'll fix that.

>Which I do not believe was fully achieved.  Any current deployment 
>who reads this doc will need to ignore it if he doesn't wish to 
>impose change work for his SPF operation.

If there is any strong discontent, other than for the SPF RRTYPE, 
please send me a message with details so that I can explain the 
problem to the Area Director.

>development issue and the migration path initially envisioned was on 
>par with what has occurred in the market albeit slow.   A note 
>should be stated with how TXT based solution is more acceptable 
>today than yester-years, hence why its allowed to be used.

The write-up I wrote is to give a quick summary of the WG 
discussions.  The persons taking the decision about the draft can ask 
for more information if they consider it as useful.

>level of support.  So until current 4408 implementations are ready 
>to begin supporting all or some of the new changes in BIS, RFC4408 
>will not be "obsolete" to them.

That text was about RFC details and "obsolete" is applicable within a 
RFC context.

>In short, I don't think this document is ready for any future 
>"Internet Standard" promotion declaration without additional changes.

The intended status of the draft is not "Internet Standard".

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 14 Jul 2013 21:20:54 -0400

On Friday, July 12, 2013 02:11:22 PM S Moonesamy wrote:
> describes version 1 of the Sender Policy Framework (SPF) protocol, whereby
> an Administrative Management Domain can explicitly authorize the  hosts

Most of the SPF protocol was non-controversial and supported by the WG.  I 
think the summary should start out to this effect.  By just listing issues and 
their resolution, I think the summary reads far too negatively.

>    was WG consensus not to standardize SPF Best-guess processing.

This should be split into two paragraphs as it's two different contexts (as 
Hector said).  I think it was the question of what 4408bis should say about 
receiver policy that was controversial.  Here's what I'd recommend:

RFC 4408 (the experimental RFC for SPF that this obsoletes) says very little 
about policy actions for mail receivers.  It was a matter of some significant 
discussion whether 4408bis should provide more or less guidance.  The (rough) 
consensus was to keep the level of guidance to receivers consistent with what 
RFC 4408 provides.

There was discussion about standardizing so called "best guess" heuristics to 
guess possible SPF policies for domains that do not publish an SPF record.  
The consensus of the group was not to do this.

>    and the local-part macro feature.  These features were not removed from
> the document given that the appeal was denied by the Responsible Area
> Director.

I think it's more correct to say that removal wasn't considered by the WG 
since it was out of scope based on the charter.  We never really go to the 
merits of it they should be removed or not.

> header field or whether to use the "Authentication-Results" header field to
> record the results of a SPF evaluation.  The working group decided to add
> both header fields in the document as they are in common use.
> 
>    There was a suggestion to reorganize the document.  It was argued that
> the document had become somewhat bloated with documentation of nuance and
> other text that has nothing to do with defining a protocol and enabling
>    The topic of obsoleting the SPF RRTYPE generated a lot of controversy
> near the end of the WGLC.  There was an intermediate conclusion about the
> topic before the WGLC and it was followed by an objection.  After the
> discussion of the topic at the IETF 83 SPFBIS WG session the conclusion
> reached was that the decision would be not to publish RRTYPE 99 and and not
> to query RRTYPE 99.  The WG consensus about the RRTYPE can be described as
> topic on the SPFBIS mailing list and the DNSEXT mailing list as the DNSEXT
> WG participants were not aware of RFC 6686.

You might add something like:

RFC 4408 suffers from an interoperability deficiency.  SPF records can be 
published in either type TXT or type SPF (99).  SPF record queries can be done 
in either type TXT or type SPF (99).  There is no common mandatory RR type for 
both publishing and retrieving SPF records.  Based on current deployment 
(virtually all domains that publish SPF records publish type TXT records), the 
working group concluded that the only logical type to make mandatory for 
publishing and receiving  was, from the perspective of interoperability, was 
TXT.  The working group also reviewed inputs from multiple participants with 
operational and implementation experience regarding the usability of type SPF.  
The rough consensus of the group was that continuing to provide the alternate 
type SPF RR type would only promote continued interoperability issues and was 
unlikely to gain significant deployment in the future.

> (8) There are no IPR disclosures referencing this document.

I think this one is relevant:

https://datatracker.ietf.org/ipr/1698/

> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 14 Jul 2013 21:26:26 -0400

> draft.  Could you double-check that?

They were used at one point, but aren't now.  I'll remove them.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 14 Jul 2013 21:31:09 -0400

> an example that has since been removed.

That's correct.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 14 Jul 2013 21:45:14 -0400

> submission is July 15 at 24:00 UTC.

Done.  Submitting momentarily.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Mon, 15 Jul 2013 07:04:57 -0700

Hi Scott,
>their resolution, I think the summary reads far too negatively.

The summary is to provide information about anything in the WG 
process that is worth writing about.  I prefer to focus on the issues 
as that is the information which I may be asked about.

>Hector said).  I think it was the question of what 4408bis should say about

Yes.

>consensus was to keep the level of guidance to receivers consistent with what

I may reuse some of the text you recommended.  I have to go through 
the SPFBIS mail archives again to review the discussion.

>merits of it they should be removed or not.

I reused some text from messages posted to this mailing list.

>unlikely to gain significant deployment in the future.

My preference is to keep it short as the working group already 
documented the above.

>https://datatracker.ietf.org/ipr/1698/

Thanks for catching this.  I'll mention the IPR disclosure in the write-up.

I'll post the write-up today.  Thanks for submitting 
draft-ietf-spfbis-4408bis-17.  I'll mention the downward-reference 
for RFC 1983.  The next step is for the Responsible Area Director to 
review the draft.

Regards,
S. Moonesamy

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 15 Jul 2013 10:54:27 -0400

On Sat, Jul 13, 2013 at 08:35:04AM +0200, Måns Nilsson wrote:
> 
> The DNSEXT participants have read, understood and dismissed 6686 as obsolete and incomplete

I think it would be extraordinarily inappropriate for the shepherd of
a doc from one WG to include in a PROTO write-up such a strong claim
about consensus on another mailing list -- particularly since no such
consensus call has been made there.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 15 Jul 2013 11:53:30 -0400

> as that is the information which I may be asked about.

Your call obviously, since it's your writeup, but I think taking the 
experimental protocol and generally agreeing it should move forward is 
certainly relevant.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 15 Jul 2013 20:26:46 +0200

On Mon 15/Jul/2013 16:04:57 +0200 S Moonesamy wrote:
>> RFC 4408 suffers from an interoperability deficiency.  SPF
>> records can be published in either type TXT or type SPF (99).
>> SPF record queries can be done in either type TXT or type SPF
>> (99).  There is no common mandatory RR type for both publishing
>> and retrieving SPF records.  Based on current deployment 
>> (virtually all domains that publish SPF records publish type TXT 
>> records), the working group concluded that the only logical type
>> to make mandatory for publishing and receiving  was, from the
>> perspective of interoperability, was TXT.  The working group also
>> reviewed inputs from multiple participants with operational and
>> implementation experience regarding the usability of type SPF. 
>> The rough consensus of the group was that continuing to provide
>> the alternate type SPF RR type would only promote continued
>> interoperability issues and was unlikely to gain significant
>> deployment in the future.
> 

I agree that Scott's text is too long.  However, I too recollect that
the WG rough consensus was that directing new or revised
implementations to query TXT type only is the most stable solution for
the foreseeable future.  That consensus was reached before the end of
the WGLC.  IMHO, it oughts to be mentioned.

Thanks for shepherding

---

From: Mark Andrews <[email-masked]>
Date: Tue, 16 Jul 2013 10:24:47 +1000

In message <[email-masked]>, Andrew Sullivan writes:
> On Sat, Jul 13, 2013 at 08:35:04AM +0200, Mns Nilsson wrote:
> > 

While I agree with this, I believe if such a call was made it would
result in such a determination.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]