ietf-dkim
[Top] [All Lists]

RE: [ietf-dkim] RE: I think we can punt the hard stuff as out ofscope.

2007-06-05 14:37:37
I am trying to punt the wildcard baggage and tree traversal bagage that is 
being acreted to meet a requirement that is out of scope. 

-----Original Message-----
From: Hector Santos [mailto:hsantos(_at_)santronics(_dot_)com] 
Sent: Tuesday, June 05, 2007 5:29 PM
To: Hallam-Baker, Phillip
Cc: Bill(_dot_)Oxley(_at_)cox(_dot_)com; ietf-dkim(_at_)kitterman(_dot_)com; 
ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] RE: I think we can punt the hard 
stuff as out ofscope.

Yeah, but don't you see Phillip, this was already done, in 
SSP for each of its drafts, and in DSAP in its expired draft.

Why are we wasting time trying to remove this NO MAIL 
concept? So that you can just create a slot later on in your spec?

I don't get it.

--
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com


allam-Baker, Phillip wrote:
Now add the three pages of boilerplate.

That is why I said four. 

-----Original Message-----
From: Hector Santos [mailto:hsantos(_at_)santronics(_dot_)com]
Sent: Tuesday, June 05, 2007 5:10 PM
To: Bill(_dot_)Oxley(_at_)cox(_dot_)com
Cc: Hallam-Baker, Phillip; ietf-dkim(_at_)kitterman(_dot_)com; 
ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] RE: I think we can punt the hard stuff as 
out ofscope.

Its not 4 pages!!! <grin>

Good show Bill!


--
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Bill(_dot_)Oxley(_at_)cox(_dot_)com wrote:
Edit/draft follows
The result of a Sender Signing Policy Check is one of 
five possible
   policies:

      (1) Some messages from this entity are not signed; 
the message
      SHOULD be presumed to be legitimate in the absence 
of a valid
      signature.  This is the default policy.

      (2) All messages from this entity are signed; all
messages from
      this entity SHOULD have a valid signature, either 
directly on
      behalf of the originator or on behalf of a third
party (e.g., a
      mailing list or an outsourcing house) handling the message.

      (3) All valid messages from this entity are signed, 
and SHOULD
      have a valid signature from this entity.  Third-party
signatures
      SHOULD not be accepted.

      (4) Signing policy for this domain is expressed at
the individual
      address level.  A second Sender Signing Policy 
Check should be
      performed specifying the individual address
      
      (5) This Domain does not send messages/This domain 
only signs 
third party messages


Done, now the rest of the WG should be happy thanks, Bill





-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org on behalf of 
Hallam-Baker, 
Phillip
Sent: Tue 6/5/2007 3:54 PM
To: Hector Santos
Cc: Scott Kitterman; ietf-dkim(_at_)mipassoc(_dot_)org
Subject: RE: [ietf-dkim] RE: I think we can punt the hard
stuff as out ofscope.
 
OK how about this as a plan

1) We do policy according to the view of scope currently
being expressed by the chairs and myself.
2) You and I submit a four page ID that registers a NOMAIL
policy for DKIM.
3) The group decides whether to accept the paragraph of
text into the text of the main draft or not during the Draft phase.


-----Original Message-----
From: Hector Santos [mailto:hsantos(_at_)santronics(_dot_)com]
Sent: Tuesday, June 05, 2007 3:48 PM
To: Hallam-Baker, Phillip
Cc: Michael Thomas; Scott Kitterman; ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] RE: I think we can punt the 
hard stuff as 
out of scope.

Hallam-Baker, Phillip wrote:

NOMAIL is out of scope, wildcards for signature policy are not.
Deja-vu.  NOMAIL is not out of scope in SSP and you need to STOP 
saying
it.   The CONFUSING VOTE that was taking - I still don't now 
show what
it meant but it was not what it would to be removed from SSP!

There are two deployment stories we need to be able to give,
 > one that meets 95% of needs with legacy infrastructure
support,  >
the second that meets 100% of needs with a minor incremental  > 
change to the legacy infrastructure.

I don't see how SSP violates this principle.

The second of these provides a slot ready made
 > for NOMAIL, (and for STARTTLE, PGP and SMIME if you like).

Oy vey! So then it is not out of scope as you said.

I am meeting your set of requirements in full. I am just
 > not doing so in such a way that my proposal is out of 
scope,  > 
that is all.

Well, I would like to know who proposed this lame rule
that it should
be out of scope when it wasn't and was clearly part of all
the sepcs
- SSP and DSAP specs.

If people voted under the disquise of a general "NO MAIL" 
concept across
the board, well, it is clear now this is not what they voted for 
because you are making provisions for it.

I don't understand why is so secret. I don't want a NO-MAIL DKIM 
policy to be dependent on a KLUDGED MX concept or  LMAP support.


--
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html













_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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