ietf-mailsig
[Top] [All Lists]

RE: candidate MASS charter

2004-09-29 15:11:40



what i do not understand is how that would improve the charter?

It's great as it is, very well done. Nice balance of focus
with wiggle room to make design decisions. 

or should the working group take one (or more) specific 
proposals and work to refine them (minimally)?

It's hard to say how technical ideas will merge or evolve, but
success is more likely if the group works from larger well documented
chunks of material.  Since there are a couple of major design
elements it may be worth contrasting and making decisions on
individual sections of documented proposals. 

Paul 

-----Original Message-----
From: owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org 
[mailto:owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Dave 
Crocker
Sent: Tuesday, September 28, 2004 8:02 PM
To: Andrew Newton; ietf-mailsig(_at_)imc(_dot_)org
Cc: Dave Crocker
Subject: Re: candidate MASS charter


 "encryption based message contents authentication" 
seemed  pretty 
clear to me. Can you suggest some different text  that would work 
better?
 Unfortunately, I think this is akin to MARID's first  milestone of 
picking an identity... and we all saw how well  that went.
 I think it should be backed up a notch to the actual  functional 
description... as in the difference between  protection against 
bounces vs. protecting the bounce address.

"message contents authentication" is quite precise and does 
not mean bounces or bounce address.  it means the message, itself.


  And if the charter can't be wordsmithed enough to state that
 the working group is attempting to stop users from seeing
 forged data or the working group is attempting to stop mail
 servers from acting on forged data or whatever, then this

well, i suppose that  "authentication of an email message and its 
contents." could be translated into "preventing false claims of 
authorship of an email message and its contents".  

what i do not understand is how that would improve the charter?


 And while we're at it, why not get the DNS RR issue out of
 the way too? 

Most/all of the candidate proposals have specific details about 
the use of DNS and/or another query service.  So I guess you are 
suggesting decomposing things into major pieces of design choice.

And I think that raises an interesting question:  is the work 
best done as an effort to do a design from the ground up, 
deciding on individual components that are then assembled 
together, or should the working group take one (or more) specific 
proposals and work to refine them (minimally)?

There is a great deal of experience that very strongly suggests 
that the latter is the only way to achieve any sort of timely 
working group output.

d/
--
Dave Crocker  <mailto:dcrocker-at-brandenburg-dot-com>
Brandenburg InternetWorking  <http://brandenburg.com>







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