minor comments on draft-ietf-marid-protocol-03.txt

"Nate Leon" <[email protected]>
Newsgroups gmane.ietf.mxcomp
Message-ID <42FE9417C0B0374B9D4234DC867819AC1F0594__43430.8167118163$1095463886$gmane$org@mailserver.corp.mailfrontier.com>
First, thanks to the authors of the docs for all of their hard work!

Sorry if this is too picky, but I think RFCs (which is hopefully where
we are headed :) should be as close to perfect as possible since they
will be around for a long time.

And now, on with the nit-picking...

Section 1.2
-----------
drop the "a"?
	use the Sender-ID checks as part of the a larger set

Should be "are"?
	While the tests as a whole or optional

Insert "as"?
	it must as performed specified


Section 1.3
-----------
Should be "ensures" (i.e. plural)
	This ensure that


Section 2
---------
Drop "to"
	SPF records to declare

Should be "a scope of pra and mfrom" ?
	spf2.0/mfrom,pra +mx +a:colo.example.com/28 -all
	This record has a version of "spf2.0", a scope of "pra", and ...


Section 2.1
-----------
Drop "with" or "via"
	When published with via the SPF RR type 


Section 2.1.5
-------------
Should be "then that record"
	then record MUST be treated 


Section 2.1.8
-------------
should probably get moved up to appear after 2.1.2


Section 3.5
-----------
maybe briefly define "terms" here?
i.e. it is used in the ABNF but not defined until 3.6.1 which will leave
a new reader wondering


Section 3.6.1
-------------
Same as above.  Maybe include something here like:
	domain-spec : See Section 3.8
	macro-string : See Section 7.1


Section 4
---------
Should be "addresses"
	a set of <ip> address 

In general, it is confusing to read this section and distinguish
between:
   <ip> - the IP address of the host under test
and
   An IP Address returned by DNS lookup triggered by an SPF record
directive

Maybe that could be clarified a little further?

Should be "a comparison"
	mechanisms that perform an comparison 

"CIDR-length" is used here for the first time without being defined
anywhere


Section 4.3
-----------
"dual-cidr-length" isn't defined anywhere until Appendix A


Section 4.4
-----------
Maybe should specify "a DNS A record query" for clarity and consistency
with Section 4.7


Section 4.5
-----------
Extra ";"
	 if the <target-name> and a validated hostname; are the same


Section 4.7
-----------
Maybe this:
	The domain-spec is expanded as per Section 7
should be:
	The <domain-spec> is macro expanded (see Section 7) and becomes
the <target-name>
to be clear/consistent. (e.g. Section 5.2)

Actually, I'd be OK with just saying "target-name" since that is already
defined back in Section 3.8. :-)
(this happens several times thru the doc)

Should be "enables"
	This mechanism enable queries 


Section 5
---------
Maybe provide an example of the deprecated "default" modifier so we know
what to ignore. :-)


Section 5.2
-----------
Should be "TXT or SPF"
	The DNS TXT record 


Section 6.2
-----------
Insert "of"
	keep the number include directives


Section 7.1
-----------
Maybe "on their mechanisms and modifiers"
	on their arguments

The difference between these two:
	o = domain of <sender>
	d = <domain>

is not well defined.  
Furthermore, I don't think "d" is described at all in the following
paragraphs.


Section 8
---------
Pick one  :-)
	is assumed to be correct true

Should be "might be" since this is probably not a valid assumption
	Since this message is eventually shown to a user


Section 12.2
------------
Include reference to DNS (1035) and/or CIDR (1519?) RFCs here?


Appendix A
----------
I think we have an extra "/" for the ip6-cidr-length scenario:

	dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
	ip4-cidr-length  = "/" 1*DIGIT
	ip6-cidr-length  = "/" 1*DIGIT

e.g. unless "//128" would be correct?

I don't think "name" should be defined in the middle of "macro-char"
Probably after "scope-id" would be more appropriate.


Appendix B.1
------------
I think this should be "192.0.2.140/30 passes"
   spf2.0/mfrom,pra mx/30 mx:example.org/30 -all
      -- any sending host in 192.0.2.128/30 or 192.168.2.140/30 passes

i.e. "0" instead of "168"




Respectfully,
Nate
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.