On Jan 12, 2009, at 6:53 PM, Murray S. Kucherawy wrote:
[Apologies for the double-send; the headers got munged by my editor.
-MSK]
Doug Otis wrote:
[...] while omitting the IP address of the SMTP client. This
prevents compliance with section 4.1 reputation check of an
authenticated m
HIP?
On Wed, Jan 14, 2009 at 7:43 AM, Toni Stoev wrote:
> On Tuesday 13 January 2009 06:27:10 Hui Deng sent:
> > May I chime in, I feel identity type is a good idea.
> >
> > But if you map DNS to other identity,
> > how network socket connection could work in that case/
>
> Shortly, like socket
On Tuesday 13 January 2009 06:27:10 Hui Deng sent:
> May I chime in, I feel identity type is a good idea.
>
> But if you map DNS to other identity,
> how network socket connection could work in that case/
Shortly, like socket connection for anycast TCP does.
You tune right in, see identity type i
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-pim-r
Eric,
Thank you for the careful reading and constructive suggestions.
> This document contains material from IETF Documents or IETF
> Contributions published before November 10, 2008 and, to the
> Contributor?s knowledge, the person(s) controlling the
> copyright in
> such materi
> The RFC Editor is asking the authors. That is the list of people
> that is readily available. If the authors cannot speak for all
> Contributors, then the document will have to wait until a work-around is
> found.
In this case, wouldn't it make sense to (temporarily?) suspend the rule that
Russ Housley wrote:
Russ the phrase COUNSEL reviewed the text is meaningless from a legal
standpoint without specifically asking particular questions. So what is
it exactly that the Counsel reviewed and is willing to issue a formal
opinion on?
Todd Glassey
John:
> I think that the cover n
Hi Doug,
At 18:53 12-01-2009, Doug Otis wrote:
(see section 3.4.1 of [MAIL]) of an address, the "pvalue" reported
along with results for these mechanisms SHOULD NOT include the local- part.
"SHOULD NOT" is not an recommendation to do something.
Are you recommending coercion to resolve conflic
John:
> I think that the cover note from the Chair of the IETF Trust,
> Ed Juskevicius, included the vast bulk of the information that
> you are requesting.
Russ, I think your note addresses several more of the issues I
was concerned about than Ed's note did. Assuming that your note
represent
The IAB is responsible for selecting one IETF Administrative Oversight
Committee (IAOC) member for a two-year term starting in March 2009. The
selection was made in accordance with BCP 101 and BCP 113.
A call for nominations was issued on 3 November 2008. Nominations for
three candidates were r
At Mon, 12 Jan 2009 19:27:02 -0500,
Ed Juskevicius wrote:
>
> Eric, Thank You for your comments and for your suggestions (below)
>
> I like your proposal for how to clarify and improve the wording of the draft
> legend text.
Thanks.
Can you advise as to when the community can expect to see a re
Murray S. Kucherawy wrote:
Doug Otis wrote:
[SPF/Sender ID debate omitted]
The draft points out in its Security Considerations (section 7.7) that issues
which may exist in the message evaluation methods it covers apply here as
well, and admonishes implementors to be aware of them. The conte
An IPR declaration [1] was recently filed for this draft. This happened
when the INTAREA working group had already passed the draft onwards and
I had initiated the IETF Last Call; the existence of the IPR was a
surprise. The IPR is not necessarily a problem, but I think it is fair
to take the d
Martin Duerst wrote:
Re. pre-5378 vs. post-5378 material, please note that in many
cases, an RFC may be post-5378, but the Internet-Drafts having
lead up to it may be pre-5378, or the lastest available Internet-
Draft may be post-5378, but earlier ones may be pre-5378.
In other words, just lookin
[Apologies for the double-send; the headers got munged by my editor. -MSK]
Doug Otis wrote:
> [SPF/Sender ID debate omitted]
The draft points out in its Security Considerations (section 7.7) that issues
which may exist in the message evaluation methods it covers apply here as
well, and admonishes
Doug Otis wrote:
> [SPF/Sender ID debate omitted]
The draft points out in its Security Considerations (section 7.7) that issues
which may exist in the message evaluation methods it covers apply here as
well, and admonishes implementors to be aware of them. The context of
this draft is not the pla
16 matches
Mail list logo
