On Thu, 03 Jul 2008 03:39:46 +0100, Douglas Otis <[EMAIL PROTECTED]>
wrote:
> Add:
>
> ADSP defines a record that can advertise the extent to which a domain
> signs outgoing mail that is publicly exchanged on SMTP port 25, as
> described in [RFC2821]. Also, how other hosts can access those recor
Folks,
Our main goal for the Dublin meeting is (yet again;-) to progress ADSP.
Hopefully we're much closer now. (I'll be sending out a bunch of
issue-specific messages in the next day/two to try close off issues
that are ready to close.)
We're currently down to meet Monday at 1pm, for 2 hours,
(This is the 1st of a bunch of what I hope will amount to a set of
"tidy-the-tracker" messages. I'd ask that we try to limit discussion
on these to cases that we really care about - we need to be
getting down to zero open issues on the overview and ADSP - thanks.)
Issue description: https://rt.ps
Issue description: https://rt.psg.com/Ticket/Display.html?id=1535
I think that ssp-04 does satisfy this.
If no-one objects, I'll ask Eliot to close this on July 11th.
S.
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-li
Issue descritption: https://rt.psg.com/Ticket/Display.html?id=1543
ssp-04 still includes the FWS, I didn't see a clear consensus on the
list either way (or else I missed some messages;-)
If we really need a strawpoll/consensus check on this please say so
and I'll start one.
Otherwise, I'll assu
Issue description: https://rt.psg.com/Ticket/Display.html?id=1547
I didn't see any consensus to mandate the use of MX and the current
text in ssp-04 seems to me to represent consensus.
Barring a significant number of calls to mandate MX, I'll ask Eliot
to close this on July 11th.
S.
__
On Wednesday 02 July 2008 22:40, Douglas Otis wrote:
> 4.3. ADSP Lookup Procedure
> ,--
>
> |If a query results in a "SERVFAIL" error response, the algorithm
> |terminates without returning a result; possible actions include
> |queuing the message or returning an SMTP error indicating a
> |tempora
Issue description: https://rt.psg.com/Ticket/Display.html?id=1553
I'm not sure that we converged totally on this, but the thread [1]
does have proposed changes, so I guess we have to wait until
the next rev of the overview, at which point we can hopefully
close this. OTOH if Jim & John are ok tha
Issue description: https://rt.psg.com/Ticket/Display.html?id=1554
Thread: http://mipassoc.org/pipermail/ietf-dkim/2008q1/009690.html
I didn't see a clear consensus on what to do for this. Since
the change calls for adding additional explanation in an area
where (it seems from the list) we're not
> On Wed, 2 Jul 2008 19:40:58 -0700, Douglas Otis <[EMAIL PROTECTED]> said:
DO> 4.3. ADSP Lookup Procedure
DO> ,--
DO> |If a query results in a "SERVFAIL" error response, the algorithm
DO> |terminates without returning a result; possible actions include
DO> |queuing the message or returning a
Stephen Farrell wrote:
> If no-one objects, I'll ask Eliot to close this on July 11th.
Sounds like a mostly editorial nit, I propose to close this
and other overview tickets when there is a new overview I-D,
maybe old reported stuff is actually addressed in a new I-D.
Frank
__
Issue description: https://rt.psg.com/Ticket/Display.html?id=1555
This seems purely editorial and attracted no discussion, so
I suggest closing it and leaving it to the editors to take
it or leave it.
If no one objects, I'll ask Eliot to close this on July 11th.
S.
Stephen Farrell wrote:
> Issue description: https://rt.psg.com/Ticket/Display.html?id=1553
>
> I'm not sure that we converged totally on this, but the thread [1]
> does have proposed changes, so I guess we have to wait until
> the next rev of the overview, at which point we can hopefully
Looki
Issue description: https://rt.psg.com/Ticket/Display.html?id=1556
Another one with no discussion so far.
In this case (maybe its the academic in me:-) the changes suggested
do seem to clarify and might head off comments later in the process,
but OTOH, maybe they'd generate more?
I'd like to kno
Frank Ellermann wrote:
> Stephen Farrell wrote:
>
>> If no-one objects, I'll ask Eliot to close this on July 11th.
>
> Sounds like a mostly editorial nit, I propose to close this
> and other overview tickets when there is a new overview I-D,
> maybe old reported stuff is actually addressed in
Now that the ssp-04 draft is out, reflecting consensus on yet more text, we'd
like to make sure we keep discussion focused on what's still undecided. To
that
end:
1. Stephen will, over the next few days, be looking at the open issues and the
mailing-list discussion, and will be looking for wh
Sorry, I missed that this was an issue on the Overview rather than the
adsp draft.
I don't think the existing text is problematic, but agree we can table
it until the new draft comes out.
Ellen
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:ietf-dkim-
> [EMAIL PROTECTED] On Be
I can't find the term "intermediary" or "end system" anywhere in ssp-04,
and the term third-party occurs only in section A.4 and the table of
contents for A.4. There is also no section 3.1.2
Is the text being objected to in this issue still present in the
document?
I do think it's important to m
Issue description: https://rt.psg.com/Ticket/Display.html?id=1557
I think these are a bunch of editorial suggestions for the editors
to take or leave as they see fit.
Barring objection, to be closed one week after overview-10 issues.
S.
PS: Since the overview editors are now in the process of
Issue description: https://rt.psg.com/Ticket/Display.html?id=1558
Thread: http://mipassoc.org/pipermail/ietf-dkim/2008q1/009735.html
Modulo some wordsmithing this seemed to attract support on the
list, so the editors should make an addition along the lines
suggested.
Barring objection, to be cl
Issue description: https://rt.psg.com/Ticket/Display.html?id=1559
Thread: http://mipassoc.org/pipermail/ietf-dkim/2008q1/009736.html
Looks like Dave and JD agreed that this change isn't needed.
This can be closed now.
Stephen.
___
NOTE WELL: This li
Issue description: https://rt.psg.com/Ticket/Display.html?id=1560
Basically a request to move a definition forward. Let's leave this
to the editors to handle.
Barring objection, to be closed one week after overview-10 issues.
S.
___
NOTE WELL: This l
Issue description: https://rt.psg.com/Ticket/Display.html?id=1561
Thread: http://mipassoc.org/pipermail/ietf-dkim/2008q1/009790.html
From the thread people seem to support the thrust of the comment, i.e.
to reduce/eliminate 2119 language where possible and definitely
avoid it (regardless of cas
Issue description: https://rt.psg.com/Ticket/Display.html?id=1562
Thread: http://mipassoc.org/pipermail/ietf-dkim/2008q1/009806.html
I didn't see very clear closure here, but it seemed like only
Jim was for deletion and Dave/Mark/Tony were ok with the current
text. That'd suggest we leave the pa
Just to make sure I understand:
The decision is to remove all hints of being normative? (Per the recent
exchange on the IETF mailing list, this won't hinge on case.)
d/
Stephen Farrell wrote:
> Issue description: https://rt.psg.com/Ticket/Display.html?id=1561
>
> Thread: http://mipassoc.
Not sure it was so strong. I'd interpret the list consensus as
being to remove all normative statements where possible with
some people (but maybe not a consensus) saying that that should
get rid of them all.
If there's something that the editors feel should be normative
in the deployment guide t
Stephen Farrell wrote:
> Not sure it was so strong. I'd interpret the list consensus as
> being to remove all normative statements where possible with
> some people (but maybe not a consensus) saying that that should
> get rid of them all.
>
> If there's something that the editors feel should be
Issue description: https://rt.psg.com/Ticket/Display.html?id=1563
Suggestion was to move overview section 3.2.1 to 5.4.
No discussion ensued.
I suggest we leave this one to the editors.
Barring objection, to be closed one week after overview-10 issues.
S.
Issue description: https://rt.psg.com/Ticket/Display.html?id=1564
Thread: http://mipassoc.org/pipermail/ietf-dkim/2008q1/009812.html
While we didn't entirely close out on this one, Dave suggested some
changes that Jim thought would be an improvement, so let's let the
editors make that change to
Dave Crocker wrote:
>
>
> Stephen Farrell wrote:
>> Not sure it was so strong. I'd interpret the list consensus as
>> being to remove all normative statements where possible with
>> some people (but maybe not a consensus) saying that that should
>> get rid of them all.
>>
>> If there's somethin
Stephen Farrell wrote:
> I agree. But this issue relates to the deployment guide, not the
> overview. If we also have a similar consensus about the deployment
> guide, then I think that makes sense but I don't remember us
> closing out on that yet (we did specifically for the overview).
ahh. mi
Stephen Farrell wrote:
> I guess the fair thing is to close it if no-one comments.
Comment... ;-) The DNSBL draft should show up as "PubReq"
soon. The Auth-header draft depends on ADSP, but as those
proposed clarifications are no normative references the
status of these drafts isn't critical.
Stephen Farrell wrote:
> Suggestion was to move overview section 3.2.1 to 5.4.
> No discussion ensued.
ADSP was / is more interesting than overview in March / now.
> I suggest we leave this one to the editors.
That might be one of the cases where having "adopted" vs.
"rejected" on public recor
33 matches
Mail list logo
