>>> I would rather have a 6 month pushback from the IESG than a spec that is
>>> dependent on the next release of Windows Server to become viable.
>The only problem is that I don't know what it means.
Someone was predicting another round of DNS wars, of the define a new
RR vs.reusing TXT variety,
>>> Alternatively, we could go through working group last call,
>>> IETF last call, and IESG push-back. For any interesting
>>> push-back, we are probably looking at delays in the range of
>>> 6 months. (That estimate is, of course, not merely
>>> theoretical.)
>
>> I would rather have a 6 mon
On Jun 16, 2006, at 4:41 PM, Hallam-Baker, Phillip wrote:
Defining a DKIM specific RR type should not prevent deployment.
Defining the DKIM specific RR within the base draft means a new
DKIM version is not required to enable its use. If there are
issues handling a DKIM specific RR, thi
> > Alternatively, we could go through working group last call,
> > IETF last call, and IESG push-back. For any interesting
> > push-back, we are probably looking at delays in the range of
> > 6 months. (That estimate is, of course, not merely
> > theoretical.)
> I would rather have a 6 month pu
> Defining a DKIM specific RR type should not prevent deployment.
> Defining the DKIM specific RR within the base draft means a
> new DKIM version is not required to enable its use. If there
> are issues
> handling a DKIM specific RR, this is a problem independent of DKIM.
> A new RR i
On Jun 16, 2006, at 3:49 PM, Paul Hoffman wrote:
At 2:58 PM -0700 6/16/06, Douglas Otis wrote:
It would be good to have a binary DNS RR defined within the base
draft.
Fully disagree. The current protocol (a TXT record that is only
used in namespaces that are specific to the DKIM protocol)
At 2:58 PM -0700 6/16/06, Douglas Otis wrote:
It would be good to have a binary DNS RR defined within the base draft.
Fully disagree. The current protocol (a TXT record that is only used
in namespaces that are specific to the DKIM protocol) is sufficient.
Depending upon how this record is us
Dave Crocker wrote:
Stephen Farrell wrote:
Our main Montreal agenda is for a) finishing base and b) kicking
off SSP-related discussions. (a) seems nicely in-hand.
I suggest that we explicitly solicit some discussion in the meeting with both
Security and DNS experts. We have made some assum
On Jun 16, 2006, at 3:08 PM, Hallam-Baker, Phillip wrote:
I would rather have a 6 month pushback from the IESG than a spec
that is dependent on the next release of Windows Server to become
viable.
The first does not delay deployment in the slightest. As far as I
am concerned its damn the
I would rather have a 6 month pushback from the IESG than a spec that is
dependent on the next release of Windows Server to become viable.
The first does not delay deployment in the slightest. As far as I am concerned
its damn the torpedoes.
The second will mean as an absolute minimum waiting
On Jun 16, 2006, at 2:39 PM, Dave Crocker wrote:
So, for example, the DNS purists could well take exception to the
choice we have made for an initial TXT record, with a new RR
outside the critical path of -base.
It would be good to have a binary DNS RR defined within the base
draft. D
Stephen Farrell wrote:
>
> Our main Montreal agenda is for a) finishing base and b) kicking
> off SSP-related discussions. (a) seems nicely in-hand.
I suggest that we explicitly solicit some discussion in the meeting with both
Security and DNS experts. We have made some assumptions about what
2006 4:35 PM
> To: Hallam-Baker, Phillip
> Cc: ietf-dkim
> Subject: Re: [ietf-dkim] Montreal agenda, other than base
>
>
> Hi Phil,
>
> That looks like it might be interesting to discuss.
>
> I hope that writing it up as draft-hallam-dkim-foo isn't too
&g
Hallam-Baker, Phillip wrote:
Damn the cutoff for the -foo drafts was last week !
You're in luck, the actual deadline in June 19 [1].
Isn't that handy:-)
S.
[1] http://www.ietf.org/meetings/cutoff_dates_66.html
___
NOTE WELL: This list operates ac
Hi Phil,
That looks like it might be interesting to discuss.
I hope that writing it up as draft-hallam-dkim-foo isn't too much
work, since that's the barrier-to-entry:-)
S.
Hallam-Baker, Phillip wrote:
I am not sure that I want to propose a different architecture, it is
conditional on wheth
I am not sure that I want to propose a different architecture, it is
conditional on whether we are going to have an incompatible backwards change or
not.
I see two cases of interest here:
Case One: Adopt SSP essentially as is without backwards incompatible change.
This is an entirely ju
We do have draft-allman-dkim-ssp-01; is there any problem with using
that as a starting point?
As Stephen says, it's in our charter as a starting point. But we have
to consider it *a* starting point, because we've already seen at least
two more views on what a signing policy/practices/poodle
Jim Fenton wrote:
Stephen Farrell wrote:
Our main Montreal agenda is for a) finishing base and b) kicking
off SSP-related discussions. (a) seems nicely in-hand.
For (b) we'd like to get anyone who'd like an agenda slot to
write up an individual I-D (before the 19th June cutoff!) and then
ask
Stephen Farrell wrote:
>
> Our main Montreal agenda is for a) finishing base and b) kicking
> off SSP-related discussions. (a) seems nicely in-hand.
>
> For (b) we'd like to get anyone who'd like an agenda slot to
> write up an individual I-D (before the 19th June cutoff!) and then
> ask the chairs
Paul Hoffman wrote:
At 3:01 PM +0100 6/7/06, Stephen Farrell wrote:
Our main Montreal agenda is for a) finishing base and b) kicking
off SSP-related discussions. (a) seems nicely in-hand.
Question (not a suggestion): why is draft-kucherawy-sender-auth-header
not on that list? The base docu
At 3:01 PM +0100 6/7/06, Stephen Farrell wrote:
Our main Montreal agenda is for a) finishing base and b) kicking
off SSP-related discussions. (a) seems nicely in-hand.
Question (not a suggestion): why is
draft-kucherawy-sender-auth-header not on that list? The base
document talks about its fu
Our main Montreal agenda is for a) finishing base and b) kicking
off SSP-related discussions. (a) seems nicely in-hand.
For (b) we'd like to get anyone who'd like an agenda slot to
write up an individual I-D (before the 19th June cutoff!) and then
ask the chairs for however many minutes you'd li
22 matches
Mail list logo
