Subject: [spfbis] Section 1 of raft-ietf-spfbis-4408bis-06

From: SM <[email-masked]>
Date: Fri, 31 Aug 2012 23:14:45 -0700

Hello,

There comments are about Section 1 of draft-ietf-spfbis-4408bis-06.

   "Furthermore, many domain owning ADMDs (ADministrative
    Management Domains, see [RFC5598]) are understandably concerned about
    the ease with which other entities can make use of their domain
    names, often with malicious intent."

The "domain owning ADMDs" wording is unclear.  As a nit, the ADMDs 
should be exapanded on first using the acronym first.

   'Compliant ADMDs publish Sender Policy Framework (SPF) records in the
    DNS specifying which hosts are permitted to use their names, and
    compliant mail receivers use the published SPF records to test the
    authorization of sending Mail Transfer Agents (MTAs) using a given
    "HELO" or "MAIL FROM" identity during a mail transaction.'

The switch from "domain holders" to ADMDs makes the above unclear.

Section 1.1 is about "Protocol Status".

  "The goal of this document is to clearly document the protocol defined
   by earlier draft specifications of SPF as used in existing
   implementations."

According to the SPFBIS Charter, the document is work based on RFC 
4408.  The charter does not mention earlier draft specifications.  I 
suggest finding a better title for the subsection and reviewing the sentence.

Section 1.2 is about "Experimental History".  RFC 6686 discusses 
about the experiments.  The quick fix would be to drop the subsection.

 From Section 1.3.3:

   'This document is concerned with the portion of a mail message
    commonly called "envelope sender", "return path", "reverse path",
    "bounce address", "5321 FROM", "MAIL FROM", or RFC5321.MailFrom.
    Since these terms are either not well defined or often used casually,
    this document uses "MAIL FROM" for consistency.  This means the
    RFC5321.MailFrom as defined in [RFC5598].  Note that other terms that
    might superficially look like the common terms, such as "reverse-
    path", are used only with the defined meanings from normative
    documents.'

There is a normative reference to RFC 5321 and RFC 5598.  The 
definitions in the  document are a mix of RFC 4408 and RFC 5598.  I 
suggest choosing one of the for consistency.

In Section 1.3.5:

   "There are [RFC4408] features that are marked "deprecated".  In the
    context of this document, deprecated means that senders SHOULD NOT
    publish SPF records that make use of such features because they might
    be removed entirely in future updates to the protocol.  Such features
    do, however, remain part of the SPF protocol and receiving systems
    MUST support them unless this document explicitly says otherwise."

The above introduces two new RFC 2119 key words.  The text mentions 
senders while ADMDs are mentioned in previous subsections.  I suggest 
dropping the RFC 2119 key words.  There isn't any mention of 
"deprecated" in Section 3.  Section 5.5 deprecates the "ptr" mechanism.

Regards,
S. Moonesamy

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 2 Sep 2012 13:42:33 -0700

On Fri, Aug 31, 2012 at 11:14 PM, SM <[email-masked]> wrote:
> The "domain owning ADMDs" wording is unclear.

In what sense?

> As a nit, the ADMDs should be
> exapanded on first using the acronym first.

Agreed.

> According to the SPFBIS Charter, the document is work based on RFC 4408.
> The charter does not mention earlier draft specifications.  I suggest
> finding a better title for the subsection and reviewing the sentence.

...or removing it.  Since this one will obsolete RFC4408, isn't that implicit?

> Section 1.2 is about "Experimental History".  RFC 6686 discusses about the
> experiments.  The quick fix would be to drop the subsection.

...or include a reference to RFC6686 as recommended reading.

> There is a normative reference to RFC 5321 and RFC 5598.  The definitions in
> the  document are a mix of RFC 4408 and RFC 5598.  I suggest choosing one of
> the for consistency.

Agree.

> The above introduces two new RFC 2119 key words.

That would require updating RFC2119, which we aren't doing.  I don't
think this is a correct characterization.  Rather, it merely defines
one term.

> The text mentions senders
> while ADMDs are mentioned in previous subsections.  I suggest dropping the
> RFC 2119 key words.  There isn't any mention of "deprecated" in Section 3.
> Section 5.5 deprecates the "ptr" mechanism.

I don't agree.  An ADMD is an conceptual entity, while a sender is an
identity in the context of email.

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Sun, 02 Sep 2012 15:02:45 -0700

Hi Murray,
>In what sense?

If I recall correctly, and after referring to RFC 5598, 
ADministrative Management Domains was introduced as there are 
different groups involved from an operational perspective.  The 
"domain owner" is the entity who registered the domain.  It's mixing 
two different things.

>...or removing it.  Since this one will obsolete RFC4408, isn't that implicit?

That's an alternative.  There will be a "status of this memo" section.

>...or include a reference to RFC6686 as recommended reading.

That's one more document

>think this is a correct characterization.  Rather, it merely defines

I wrote the comment as a note of a change.  I didn't word the comment properly.

>identity in the context of email.

Yes.  The text does not follow what was stated in Section 1.

Regards,
S. Moonesamy (speaking for myself)

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 03 Sep 2012 01:06:28 -0400

> suggest choosing one of the for consistency.

The document uses "MAIL FROM" throughout unless I missed something.

> "deprecated" in Section 3.  Section 5.5 deprecates the "ptr" mechanism.

I don't understand this comment beyond the bit about ADMDs.  Why does section 
3 matter?  Why remove the 2119 words?

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Sun, 02 Sep 2012 23:06:40 -0700

>3 matter?  Why remove the 2119 words?

The text mentions SPF records.  SPF records are discussed is Section 
3.  The question which arises is about why is it important to add a 
"SHOULD" not" and a "MUST".  Quoting from RFC 2119:

  "Imperatives of the type defined in this memo must be used with care
   and sparingly."

Regards,