Subject: [spfbis] Nits about draft-ietf-spfbis-4408bis-16

From: S Moonesamy <[email-masked]>
Date: Fri, 12 Jul 2013 08:43:10 -0700

Hi Scott,

I ran draft-ietf-spfbis-4408bis-16 through id-nits and it flagged two 
errors.  The error about RFC 5598 can be ignored.  RFC 5782, flagged 
as an error, should be an informative reference instead of a normative one.

In the Abstract:

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

I suggest:

   "This document 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."

You could add the abbreviation after the expanded form if you prefer 
to keep it.

Section 4 mentions "Receiving ADMDs".  You could use that instead of 
"receiving host".

There is a typo in Section 2.5: "Appencix C of [RFC5451] provides".

I'll suggest a change to Section 13.3.  This is to make it clear to 
IANA and make their work easier.

   IANA is requested to change the reference for the exp and redirect
   modifiers in the Modifier Names registry, under Sender Policy
   Framework Parameters, from [RFC4408] to this document.  Their
   status is unchanged.

Could you add a "NOTE TO RFC EDITOR:" at the beginning of Appendix I 
and Appendix J?

If you are okay with any of the above you could make the changes to 
your local copy.  A draft can be submitted if the Responsible Area 
Director requests that.

Regards,
S. Moonesamy (as document shepherd)

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 12 Jul 2013 12:03:59 -0400

> You could add the abbreviation after the expanded form if you prefer

I'll put it after.  At some point there was a comment about that text and 
dealing with the abbreviation in it's first appearance, so I don't want to 
remove it.

> Section 4 mentions "Receiving ADMDs".  You could use that instead of

The check is done at a specific host, so I think it's correct as is.  The 
decision to make such a check and the policy applied based on the results of 
the check are an ADMD decision, but the actual implementation is in a specific 
receiving host.

> There is a typo in Section 2.5: "Appencix C of [RFC5451] provides".

I don't see the typo.  What specifically?

>    Framework Parameters, from [RFC4408] to this document.  Their

OK.

> Could you add a "NOTE TO RFC EDITOR:" at the beginning of Appendix I

OK.

> your local copy.  A draft can be submitted if the Responsible Area

OK.  I mostly agree, but please let me know what you think about receiving 
host and give me more specificity about the typo you see in 2.5.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Fri, 12 Jul 2013 15:44:56 -0400

> dealing with the abbreviation in it's first appearance, so I don't want to

The proper technical writing style is to spell it out first, followed by 
the parenthetical acronym:

        Administrative Management Domain (ADMD)

However, since its just the abstract, you will to repeat it once more in 
the intro and there you can begin again as above before just using the 
acronym in the reminder of the doc.

The same is true for other abbreviated terms and their acronyms.

--
HLS

---

From: S Moonesamy <[email-masked]>
Date: Fri, 12 Jul 2013 13:41:19 -0700

Hi Scott,
>dealing with the abbreviation in it's first appearance, so I don't want to

Ok.

>the check are an ADMD decision, but the actual implementation is in 

Ok.

>I don't see the typo.  What specifically?

"Appendix" instead of "Appencix".

>host and give me more specificity about the typo you see in 2.5.

I am ok if you think that the "receiving host" correct.

I noticed that the reference to RFC 1983 should be normative instead 
of informative.  It's going to cause a downward reference.

I was doing a final ABNF check for my write-up.  I saw the following 
defined in Appendix A but not used:

  authserv-id
  reasonspec

Could someone please verify that?

Regards,