Sorry if these questions appear to be naive or already hashed out.
I tried some searching on the list archives, but did not get any
immediate hits that gave me answers.
Questions and comments are based upon the draft
draft-ietf-marid-csv-csa-02.html:
* The draft expiration is Aug 21, 2005. Will there be a new revision?
Does CSV have a future?
* In step 1 of Section 4, is the domain name associated with the
SMTP client obtained from the EHLO command? If so, why not
state that.
I recommend to provide all necessary information (or explicit
references to it) in the authentication/authorization steps.
This will make it easier for implementors to create conforming
implementations.
* I need some clarification of the use of "bit-fields". When
using the term "bit-fields" there is direct implication that
the field has 16 distinct values based on 0-15 bits of the
16 bit integer. For example:
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 0 |
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Contains two distinct values versus the single integer value of 6.
* Does bit-field numbering start at 0 or 1? Looking at the description
for Weight, it mentions bit value 1 and 2. Does this indicate the
1st and 2nd least significant bits? If so, why doesn't bit numbering
start with 0?
* I'm confused on the relationship of the Weight Bit Values and
Weight Summed Values. Is this have to do with the weight summation
described in RFC-2782?
* Does the Port part of the record have any real value? If an
SMTP server encounters a EHLO domain that does not have a CSA record,
is the server supposed to utilize the Port field in a previous query
under the same domain?
There seems to be some "walking" implications in subsequent text
justifying the setting of Port. This information should be included,
or explicitly referenced, during the authentication/authorization
step.
* Should "walking" even be allowed? This seems to increase the cost
of failure and one has to deal with what really constitutes a
top-level domain. For example, what about country-based roots:
com.au, or tx.us? Does one consider the root domain to always be
the first domain (right-most) of a full domain name?
Is it reasonable to require a sender to explicitly define SRV records
for each EHLO name they will use, therefore avoiding any "walking"?
* Does an IP address match indicate _authentication_? And does
a Weight of 2 indicate _authorization_?
If so, the parenthetical comment in the following (Section 4):
If the sending SMTP client[ID-CSV] both authenticated and
authorized (with Weight equal 2 and the IP address matching),...
needs to be reverse to match the respective order of "authenticated
and authorized".
--ewh
_______________________________________________
ietf-clear mailing list
ietf-clear(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-clear