On Sep 1, 2005, at 6:26 PM, Earl Hood wrote:
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?
There will be a presentation made at the next MAAWG. I am also
writing a draft to explain how HELO and signing-domain provide a name
basis for establishing accountability. The aspect of protecting
system and network resources is best done using HELO, rather than a
signature, however the same name basis can be applied. Signed email
will have a future and once a name basis becomes more common, it will
become more apparent the value HELO offers.
* 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.
These are good inputs.
* 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
Actually the IETF has a practice of defining the MSB as bit 0. This
can be confusing when describing bit settings. Rather than
specifying the bit ordering, the settings were defined by value. A
bit with a value of 1 would be bit 15 per IETF big endian
conventions, and bit 0 per common little endian architectures. Bit
values of 1, 2, or 4 was an attempt to avoid this ambiguity.
Contains two distinct values versus the single integer value of 6.
There are two tables where one indicates the resulting combined values.
* 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?
The LSB bit can offer a value of 1 or 0. When asserted, this bit
offers a value of 1.
* 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?
No. This was to clarify the bit value approach.
* 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.
There was an attempt made to limit the number of lookups required.
This was done by not requiring a search in any direction by making
the assertion apply for all sub-domains. The depth of this label
tree was kept constrained as well. The concept was to allow a domain
to proclaim all authorized clients will have a CSA record. The
initial concept of the CSA did not include this approach, and the
Port field has been isolated from the rest of the associated functions.
* 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"?
Dave Crocker and John Levine were proponents of this approach which
has been replicated to a fashion within the SSP draft. The SSP draft
requires upward 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".
Good point.
-Doug
_______________________________________________
ietf-clear mailing list
ietf-clear(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-clear