ietf-mxcomp
[Top] [All Lists]

Re: Draft Charter

2004-03-16 20:00:51

In 
<C6DDA43B91BFDA49AA2F1E473732113E0A19D6(_at_)mou1wnexm05(_dot_)vcorp(_dot_)ad(_dot_)vrsn(_dot_)com>
 "Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com> writes:

I think that it is very important to be able to create a system that
is useful both during them SMTP session, and after.  A system that,
for example, requires a challenge-response during the SMTP session
[...]

As for challenge-response, I think that is now so discredited that 
there is no way anything could happen in three months.

When I mentioned "challenge-response", I meant the very general term
as in CRAM, and not the common "challenge emails that require 'proof'
of a human".  There have been suggestions of adding a C-R system to
the SMTP session to augment the TCP sequence numbers in authenticating
the IP address.  If any proposal *required* this, it might rule out
the use in an MUA.

Now, I don't claim to be a universal security expert, let alone
someone who helps set industry wide definitions of terms.  So, maybe
my use of C-R is wrong, or maybe you really mean that things like CRAM
have been discredited.  If either of these are the case, please let me
know.


Is this a valid requirement for the charter?  All the references to
"MTA" in the charter kind of makes it sound like being able to work in
the MUA is not important.

I think the references bind to the originating MTA. I don't think the 
recieving MTA is referenced as the focus of the work.

There are mentions of "peer MTAs" and "recipient MTAs" in the charter
text. 


Should this be a requirement for the charter also?  Or, should we
leave it up in the air?

The charter describes only the scope of the work, not the requirements
for the work. So it is good as written 

I have not been seriously involved in IETF work groups before, but I
was under the impression that requirement documents in the charter
were not unheard off.  (And, yes, I have read the "Tao of IETF" and
the WG RFC and such to try to get up to speed.)


-wayne



<Prev in Thread] Current Thread [Next in Thread>