Subject: [dmarc-ietf] Updated Draft Charter for Review

From: "J. Trent Adams" <[email-masked]>
Date: Tue, 23 Jul 2013 16:56:45 -0600

As the holder of the pen on the draft charter for the proposed DMARC WG,
I have taken the input from the list and incorporated it into an update:

http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC

As a reminder, this includes the guidance provided by Russ and Barry
that we treat the base specification as being an Individual Submission
that is AD Sponsored.  The scope and identified items of work follow on
that assumption.

Please take a look at it and reply with your comments so we can address
as much of them as possible prior to the meeting.  Otherwise, I look
forward to the conversation in Berlin next week.

Thanks,
Trent

-- 
J. Trent Adams

Profile: http://www.mediaslate.org/jtrentadams/
LinkedIN: http://www.linkedin.com/in/jtrentadams
Twitter: http://twitter.com/jtrentadams

---

From: Tim Draegen <[email-masked]>
Date: Tue, 23 Jul 2013 20:02:46 -0400

> http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC

Hey Trent, thanks for doing this.  I support this effort, admit to not being an expert of IETF process, and have a slew of largely editorial nits:

DMARC allows a sender to indicate that its legitimate emails are protected by SPF and/or DKIM, matching the validated sending domains with the sender's email address domain in the RFC5322:From field (aka "identifier alignment"), and advises a receiver what it should do if neither of those authentication methods yields a relevant authenticated identifier passes, or the identifiers fail to align, for a received message. It also provides a reporting mechanism, from receivers back to domain owners.

This sentence no longer feels accurate:

Such capabilities over the public Internet are unusual and their use is still being explored not yet well-understood.

This one is hard for me to parse:

The working group will explore possible extensions to the base, to address limitations of the mechanism in particular scenarios or for added capabilities, and provide technical implementation guidance.

How about:

The working group will explore possible extensions to the base, to address context-specific limitations of the mechanism, to consider added capabilities, and to provide technical implementation guidance.

Typo:

The guid(e) will catalog..

OK!  For actual content:

The initial charter for this working group does not include revising the base specification,..

I wish there was a way to allow changes to the base specification aside from "bits over the wire" changes (with a heavy nod towards maintaining interoperability), so that readability and clarity can be tackled.

Thanks again for putting this together,
=- Tim

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 23 Jul 2013 21:43:02 -0400

> forward to the conversation in Berlin next week.

I really don't understand why the DMARC base spec can adequately be developed 
by an outside group and AD sponsored, while a BCP to use that spec needs an 
IETF WG?  If the expertise is in the group writing the base spec, they should 
just do the BCP too.  I think at this point it's a working group to have a 
working group.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Jul 2013 05:23:54 +0100

> http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC

I think the paragraph that bothered some as too 'marketing' oriented has 
been productively transformed into a pedantic, academic style.  Much 
more credible.  Good job.

By way of demonstrating that the text must be asymptoting nicely, 
herewith my nitpicks...

    well-known company (aka, "brand")
    ->
    well-known company (also called "brand")

{ aka is an extreme colloquialism; besides being too informal for 
something this official, this sort of text is purported to be a special 
challenge for those who do not suffer English as their native language. 
  fwiw, eg and ie also fall into this category, I'm told. }

    trust-based layer  ->  trust-oriented layer

{ besides suspecting the latter is more accurate, it bugs me to see 
'based' used twice in close proximity... }

    matching the validated sending domains
    ->
    matching the validated domains

{ as an example, rfc5321.mailfrom is a return address and might have had 
nothing to do with sending.   what?  you thought I was kidding about 
nit-picking? }

    field (aka "identifier alignment") -> ...

    Individual Submission (a.k.a. "Area Director Sponsored") for publication
    ->
    Individual Submission for publication, which is sponsored by an Area 
Director.

     and provide ->  and will provide

{ parallel construction }

     practice or bits over the wire
     ->
     practice, in particular the bits over the wire,

     need to be added as extensions, rather
     ->
     need to be additions, rather

     This permits unmodified ->  This will permit unmodified

Oops.  Not a nit-pick:

     a mechanism for ensuring the RFC5322.From field can be relied upon
     as the primary means of DMARC identifier alignment

I can parse the language, but have no idea what this means, in spite of 
knowing the gist of what's intended.  This is obscure/confusing enough, 
I can't even suggest a fix.

     failures of DMARC policy  ->  failures of the DMARC mechanism

{ in the abstract, yeah, it's probably a policy failure; but let's keep 
it mundane; the procedure doesn't work in this scenario. }

    determine the organizational domain responsible for sending mail.
    -> {add}
    An Organizational Domain is the basic domain domain name obtained
    through a public registry, such as example.com or example.co.uk.

{ The term Organizational Domain is not in common use, so it should be 
explained.  Also the text explaining the term at dmarc.org/overview.html 
really isn't correct, as demonstrated by the .co.uk example. }

    leverage the public suffix list
    ->
    use an information "public suffix" list

    solution will not scale
    ->
    solution will not scale, and that the current list often is
    inaccurate

    This working group recognizes work on a solution to be out of scope,
    however, depending on work in other groups, it would be in scope to
    explore extending the base specification to accommodate that work.
    ->
    The task of defining a standard mechanism for identifying
    organizational domain is out of scope for this working group.
    However the working group can consider extending the base DMARC
    specification to accommodate such a standard, should it be developed
    during the life of this working group.

    The guid will -> The guide will

    Defining a useful, common set of RUA reporting options
    ->
    Defining a useful, common set of reporting options for the addresses
    to which aggregate feedback is to be sent (RUA)

    For reference, draft-crocker-dmarc-bcp-02 is a proposed draft of the
    guide for input to this working group.
    ->
    draft-crocker-dmarc-bcp-02 will serve as the starting point for the
    implementation and deployment guide.

Jet lag sucks.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 23 Jul 2013 22:23:25 -0700

> just do the BCP too.  I think at this point it's a working group to have a

There have been presented plenty of things about the DMARC base
specification that need tuning in terms of language, layout, etc., but I
believe everything that's been identified so far can be resolved during the
mandatory IETF-wide Last Call, or the intervening time.  In particular,
there has not to date (including its life as an I-D and also a long period
before that) been presented anything like "this whole idea is totally
broken" or "this particular part needs to go back to the drawing board".
Spinning up a working group merely to tune language or clarify things is a
lot of expense for minimal return.

On the other hand, the "Using" document is roughly skeletal and needs a ton
of work, and there have been identified several other topics related to
DMARC that need resolution for DMARC to be completely successful, and there
is some measure of community agreement on them.  That's real work that
needs doing.  What the BoF will attempt to determine is if the community
interested in doing the work is large enough and dedicated enough to
warrant the expense of spinning up a working group.

I don't understand why the group containing the expertise is to be
automatically disqualified from making this request merely because it
worked on the base proposal for a long time externally, both privately and
publicly, before bringing it to the IETF.  If the complaint is that the
group's process has been too closed and exclusive to date, why would we
want to discourage it from opening up to public scrutiny and input?

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 24 Jul 2013 01:28:38 -0400

> want to discourage it from opening up to public scrutiny and input?

You wouldn't.  Which is exactly why the working group should work through the 
details of the base spec too.  I think the premise that says you need an IETF 
working group to do the using document, but not to finish the base spec is 
illogical.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 23 Jul 2013 22:29:03 -0700

> forward to the conversation in Berlin next week.
Recognizing that the charter is still subject to edits especially as a
result of the Berlin discussion, I think this looks fine to me as a basis
for that discussion.  I concur with Dave's nits, but I don't feel strongly
about any of them (he's jet lagged, I'm just tired).

One nit of my own: You can take the version number out of the second draft
reference, since the first one doesn't name a specific version and the
number could change before the working group actually charters.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 23 Jul 2013 22:57:42 -0700

> working group to do the using document, but not to finish the base spec is
You've ignored the first paragraph in my earlier message.

The proposal of working on the document as an Individual Submission does
not mean it is immutable.  It will go through an IETF Last Call just like
any other, and it will be required to accommodate any sustained feedback
received.

Rather, the claim is that the review comments that have been posted to
date, inclusive of your July 14th review -- which was very useful, by the
way, in spite of the "secret group" jab -- are not of sufficient severity
to send the whole thing back to the drawing board in the context of a
working group, which is an expensive prospect for everyone involved
(particularly the sponsoring AD).  A new working group's time and energy
would be better spent working on the engineering problems and informational
material the base document doesn't already deliver.

On the other hand, I would object to the creation of a working group merely
to satisfy the accusation that the developers have been operating in
secret, especially since the base draft was made widely available for
public review and comment over 18 months ago, when work that is largely
editorial is all that's been identified as needing attention.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Jul 2013 07:57:26 +0100

On 7/24/2013 6:28 AM, Scott Kitterman wrote:
>>> I really don't understand why the DMARC base spec can adequately
>>> be developed by an outside group and AD sponsored, while a BCP to
>>> use that spec needs an IETF WG?
...
>> worked on the base proposal
...
> working group to do the using document, but not to finish the base spec is

Scott,

You persist in making a process complaint, when there is no process 
error.  Since you feel so strongly otherwise, you have the burden of 
documenting it.  After /many/ rounds of your invoking this claim, you 
have yet to document the error.

And then there is the small matter of our having no technical work to do 
that has community support, and your continued failure to document 
otherwise.

Let's have a working group when there is no technical work to do? 
Please, no.

And then there is your above response to Murray that looks suspiciously 
like an ad hominem.  Since those are not permitted in the IETF, I'm sure 
you didn't intend it, but it suggests that your frustration is getting 
in the way of making cogent arguments for your case.

In fact your next sentence purports to be some sort of logical 
conclusion based on your apparent ad hominem.  Really?  In what system 
of logic does that work?

I've no idea why you think that repeating the same complaint, after 
getting the same, concrete explanations, will somehow produce a 
different outcome.

d/

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 24 Jul 2013 09:07:57 -0400

> any other, and it will be required to accommodate any sustained feedback

I've already said I don't think that the proposed approach is adequate and 
(believe it or not) I am trying to minimize how much I repeat myself.

> material the base document doesn't already deliver.

To my knowledge, there have been less than a handful of reviews (I didn't go 
back and look, so that may be wrong) and more than one of them carried caveats 
that the reviews were somewhat cursory.  My conclusion is that there has been 
little serious review and that it's premature to conclude anything from the 
ones that have been done other than that the document is no where near ready 
for publication.

That said, I agree with the general premise that changes to bits on the wire 
are unlikely to be needed, but that doesn't mean the document doesn't need 
significant work.

Secret group isn't a "jab".  It's a fact.

> editorial is all that's been identified as needing attention.

I don't get this.  Dmarc-dev is a private mailing list that only certain 
parties can participate in that has been the venue for review and discussion 
of changes to the spec up to now.  Yes, there have been versions made 
available to the publc for comment, but then those comments have been 
adjudicated in secret.  This is all fact.  Public input to a private process 
is not an open approach.

I tried to approach the charter as Trent Adams requested:

> that is AD Sponsored.

If I start with the assumption that this is the correct approach, then I don't 
think an IETF working group to write a BCP makes sense.  I still think having 
the group do some serious work on improving the base spec makes sense (but you 
knew that), but comments weren't solicited on that point and so I was 
attempting to respond in the context that was requested.

I think I'm just going to sit out further charter discussions because I don't 
think I'm likely to change anyone's mind at this point so I'm likely to just 
be (more of) a distraction.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Jul 2013 15:18:25 +0100

...
> I've already said I don't think that the proposed approach is
> adequate and (believe it or not) I am trying to minimize how much I
> repeat myself.

Oh?

>> Rather, the claim is that the review comments that have been posted
>> to date, inclusive of your July 14th review -- which was very
>> useful, by the way, in spite of the "secret group" jab -- are not
>> of sufficient severity to send the whole thing back to the drawing
>> board in the context of a working group, which is an expensive
>> prospect for everyone involved (particularly the sponsoring AD).  A
>> new working group's time and energy would be better spent working
>> on the engineering problems and informational material the base
>> document doesn't already deliver.
>
> To my knowledge, there have been less than a handful of reviews (I

Perhaps you did not notice the reference to /18 months/ of public access 
to the specifications and discussion of it?

Yes, there have been few, formal IETF reviews.  More are in the 
pipeline.  And (repeating this one more time, possibly making a baker's 
dozen) if any of them -- or any other review -- produces a need for 
technical work, then that will affect how things are pursued.

However -- yet one more time -- in 18 months, no one has generated 
community interest in modifying the bits over the wire.

> didn't go back and look, so that may be wrong) and more than one of
> them carried caveats that the reviews were somewhat cursory.  My
> conclusion is that there has been little serious review and that it's

Your conclusion is wrong.  But ultimately all that matters is your 
convincing others that there is technical work to be done and in spite 
of your sustained pleading, it doesn't appear (to me, at least) that 
you've succeeded.

> premature to conclude anything from the ones that have been done
> other than that the document is no where near ready for publication.

Premature?  18 months?  Adoption covering 60% of the world's email 
traffic?  Are you serious?

>> On the other hand, I would object to the creation of a working
>> group merely to satisfy the accusation that the developers have
>> been operating in secret, especially since the base draft was made
>> widely available for public review and comment over 18 months ago,
>> when work that is largely editorial is all that's been identified
>> as needing attention.
>
> I don't get this.  Dmarc-dev is a private mailing list that only
> certain parties can participate in that has been the venue for review
> and discussion of changes to the spec up to now.

Oh.  I see the problem.  You don't understand that 
[email-masked] has been public for 18 months and, of course, 
this IETF list has been open for months.

You want the issue to be the fact that the core development group has a 
closed mailing list.  Apparently you aren't aware that such activity is 
quite common.  What matter is what happens /now/.  IETF process is being 
followed.  It will continue to be followed.  I'm sorry you don't like it.

> If I start with the assumption that this is the correct approach,
> then I don't think an IETF working group to write a BCP makes sense.

Why?  Is it not useful work?  Is there no community interest in doing 
it?  What other process or substantive objection are you claiming 
justifies your position?

> I still think having the group do some serious work on improving the
> base spec

Oh?  Excellent!  That means that you know of "improvements" that are 
needed and that have community support?  Who?  Where is this documented?

d/

---

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Jul 2013 15:25:18 +0100

...

Oh?

d/

---

From: "Kelley, John" <[email-masked]>
Date: Wed, 24 Jul 2013 14:37:04 +0000

+1

John Kelley

On Jul 24, 2013, at 1:29 AM, Murray S. Kucherawy <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Jul 23, 2013 at 3:56 PM, J. Trent Adams <[email-masked]<mailto:[email-masked]>> wrote:
As the holder of the pen on the draft charter for the proposed DMARC WG,
I have taken the input from the list and incorporated it into an update:

Recognizing that the charter is still subject to edits especially as a result of the Berlin discussion, I think this looks fine to me as a basis for that discussion.  I concur with Dave's nits, but I don't feel strongly about any of them (he's jet lagged, I'm just tired).

One nit of my own: You can take the version number out of the second draft reference, since the first one doesn't name a specific version and the number could change before the working group actually charters.

-MSK
_______________________________________________
dmarc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dmarc

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 24 Jul 2013 09:15:59 -0700

> ones that have been done other than that the document is no where near

This means I can arbitrarily delay progress or force layers of additional
process on any work I like just by saying "Here's a bunch of editorial
stuff I found.  I didn't really read it very hard, but I bet I might find
something major if I did."  If we are to make process decisions based on
nebulous claims of possible future feedback that may or may not contain a
showstopper, our ability to be usefully productive will plunge.  How long
are we to wait?

> adjudicated in secret.  This is all fact.  Public input to a private

Your premise is incorrect.  Nothing has been done in private in the last
year and a half.  The dmarc-dev list has not been the primary venue for
document development in that time, dmarc-discuss has, and that's been an
open and public list since its inception.

-MSK

---

From: "J. Trent Adams" <[email-masked]>
Date: Wed, 24 Jul 2013 10:19:29 -0600

Tim -

On 7/23/13 6:02 PM, Tim Draegen wrote:
> On Jul 23, 2013, at 6:56 PM, J. Trent Adams <[email-masked]
> <mailto:[email-masked]>> wrote:
>>
> Hey Trent, thanks for doing this.  I support this effort, admit to not
> being an expert of IETF process, and have a slew of largely editorial
> nits:
>
> /DMARC allows a sender to indicate that its legitimate emails are
> protected by SPF and/or DKIM, matching the validated sending domains
> with the sender's email address *domain* in the RFC5322:From
> field (aka "identifier alignment"), and advises a receiver what it
> should do if neither of those authentication methods *yields a
> relevant authenticated identifier* passes, or the identifiers fail
> to align, for a received message. It also provides a reporting
> mechanism, from receivers back to domain owners./
>
Done.

> /Such capabilities over the public Internet are unusual and their use
> is *still being explored* not yet well-understood./
> /
> /
Done.

> /
> /
> /The working group will explore possible extensions to the base, to
> address limitations of the mechanism in particular scenarios or for
> added capabilities, and provide technical implementation guidance./
> /
> /
> How about:
>
> /The working group will explore possible extensions to the base, to
> address context-specific limitations of the mechanism, to consider
> added capabilities, and to provide technical implementation guidance./
> /
> /

Done.

> Typo:
>
> /The guid*(e)* will catalog../
> /
> /
Done.

> /
> /
> OK!  For actual content:
>
> /The initial charter for this working group does not include revising
> the base specification,../
> /
> /
> I wish there was a way to allow changes to the base specification
> aside from "bits over the wire" changes (with a heavy nod towards
> maintaining interoperability), so that readability and clarity can be
> tackled.

Given Murray's response to Scott on a similar point, I think that most
(all?) of the copy-edit and clarification edits can be made during the
last call.  But perhaps someone will offer a creative solution that
folks can get behind.

Thanks,
Trent

> [email-masked]

-- 
J. Trent Adams

---

From: "J. Trent Adams" <[email-masked]>
Date: Wed, 24 Jul 2013 10:31:00 -0600

Dave -

On 7/23/13 10:23 PM, Dave Crocker wrote:
> I think the paragraph that bothered some as too 'marketing' oriented
> has been productively transformed into a pedantic, academic style. 
> Much more credible.  Good job.
>
Wow, I think that's the first time I've been complimented for being a
pedantic academic since I turned in my thesis on galactic photometry. 
Usually I have to hide that part of my personality.  Thanks!

> something this official, this sort of text is purported to be a
> special challenge for those who do not suffer English as their native
> language.  fwiw, eg and ie also fall into this category, I'm told. }

Done

> 'based' used twice in close proximity... }
Done
> { as an example, rfc5321.mailfrom is a return address and might have
> had nothing to do with sending.   what?  you thought I was kidding
> about nit-picking? }
>
Done
>    field (aka "identifier alignment") -> ...
Done
>    Individual Submission for publication, which is sponsored by an
> Area Director.
>
Done
> { parallel construction }
Done
>     practice, in particular the bits over the wire,
Done
>     need to be additions, rather
Done
>     This permits unmodified ->  This will permit unmodified
Done
> I can parse the language, but have no idea what this means, in spite
> of knowing the gist of what's intended.  This is obscure/confusing
> enough, I can't even suggest a fix.
>

Yeah, this was a tough one.  There was mixed interest in what to do
about RFC5322.From fields that contain multiple domains.  A few folks
indicated they wanted to see how to deal with that issue, while others
wanted to stay clear of taking on "display-name" abuse.

I have a feeling that this would be a fantastic topic to explore in the
BoF.  Perhaps folks will come up with a creative way to thread the
needle here.
> { in the abstract, yeah, it's probably a policy failure; but let's
> keep it mundane; the procedure doesn't work in this scenario. }
Done
> explained.  
Done

> Also the text explaining the term at dmarc.org/overview.html really
> isn't correct, as demonstrated by the .co.uk example. }
>
Thanks, I'll pass that along to the editor of content on the DMARC.org site.

>    use an information "public suffix" list
Done
>    solution will not scale, and that the current list often is
Done
>    during the life of this working group.
Done
>    The guid will -> The guide will
Done
>    to which aggregate feedback is to be sent (RUA)
Done
>    implementation and deployment guide.
Done
> Jet lag sucks.

If you're able to offer up this level of useful specificity while
jet-lagged, maybe you should fly around more!

Thanks again,
Trent

-- 
J. Trent Adams

---

From: "J. Trent Adams" <[email-masked]>
Date: Wed, 24 Jul 2013 10:31:58 -0600

Murray -

On 7/23/13 11:29 PM, Murray S. Kucherawy wrote:
> result of the Berlin discussion, I think this looks fine to me as a
> basis for that discussion.  I concur with Dave's nits, but I don't
> feel strongly about any of them (he's jet lagged, I'm just tired).
>
> One nit of my own: You can take the version number out of the second
> draft reference, since the first one doesn't name a specific version
> and the number could change before the working group actually charters.

Done.

Thanks,
Trent

-- 
J. Trent Adams

---

From: Mike Jones <[email-masked]>
Date: Wed, 24 Jul 2013 10:17:29 -0700

Trent, 

Having just read through the comments in this thread and the updated draft charter, I agree with Murray and support this version as a starting point for the Berlin discussion.  Sorry I won't be able to take part in that discussion in Berlin!

Thanks,
Mike

Mike Jones
Agari
[email-masked]
Skype: jnzmike1
703-728-3978 (cell)

---

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Jul 2013 18:28:51 +0100

> wanted to stay clear of taking on "display-name" abuse.

1.  I don't recall the details of these exchanges.  Can you provide some 
mailing list pointers?

2.  If this is about multiple From: fields, those are illegal.  The 
message fails before it gets to dmarc.

3.  If this concerns the fact that the From: field may legally contain 
multiple addresses, then what's wrong with the existing text:

    11.1

    A message bearing multiple RFC5322.From identifiers is ambiguous
    under DMARC.  This includes messages with multiple RFC5322.From
    fields (which is also forbidden under [MAIL]) and a message with a
    single RFC5322.From field containing multiple entities.  There can
    also be From: fields that contain no meaningful values, such as
    RFC5322's "group" syntax.  Such messages SHOULD be rejected.

If it is something else, I've no guess.

> BoF.  Perhaps folks will come up with a creative way to thread the

mumble.

> jet-lagged, maybe you should fly around more!

Hmmm.  I thought the consensus view was that I did, even when staying home.

d/

---

From: "J. Trent Adams" <[email-masked]>
Date: Wed, 24 Jul 2013 11:42:30 -0600

On 7/24/13 11:28 AM, Dave Crocker wrote:
> 1.  I don't recall the details of these exchanges.  Can you provide
> some mailing list pointers?

I'll dig up what I can find.

> message fails before it gets to dmarc.

Right, I don't thinks that was the issue.
> If it is something else, I've no guess.

If I recall, the trick is to try and figure out if there's a way to
address common issues (even if just to call them out in the proposed
"Using DMARC" guide) without getting sucked into the morass of all the
display name abuse issues.  In the end, of course, it's possible that
there's no way to safely negotiate those weeds and we just have to avoid
them entirely.

- Trent

-- 
J. Trent Adams

---

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Jul 2013 18:47:33 +0100

On 7/24/2013 6:17 PM, Mike Jones wrote:
>
> Having just read through the comments in this thread and the updated
> draft charter, I agree with Murray and support this version as a
> starting point for the Berlin discussion.  Sorry I won't be able to take
> part in that discussion in Berlin!

surely you can remotely attend?

d/

---

From: Greg Colburn <[email-masked]>
Date: Wed, 24 Jul 2013 15:38:58 -0600

+1 on David's comments and Trent's rework.  My only nit is in the
following line at the end of the first paragraph:

"Such capabilities over the public Internet are unusual and their use is
still being explored."

"Unusual" feels awkward to me. How about:

"Such reporting capabilities over the public Internet are new and their
use is still being explored."

Greg Colburn

---

From: Franck Martin <[email-masked]>
Date: Wed, 24 Jul 2013 18:47:56 -0500 (CDT)

I like the 

"a mechanism for ensuring the RFC5322.From field can be relied upon as the primary means of DMARC identifier alignment, potentially mitigating common types of <display-name> abuse."

I would add "and other type of abuse". This would fit in what I requested while limiting the scope so it does not become an endless anti-spam document as people mentioned.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 25 Jul 2013 13:42:01 +0100

> use is still being explored."

That bit of wording was my own crafting and I agree it's awkward; I 
thought that when writing it.

The problem is that I'm not sure the underlying mechanisms are "new", 
which moved the point to statistics rather than innovation...

d/

---

From: Barry Leiba <[email-masked]>
Date: Thu, 25 Jul 2013 11:34:49 -0400

Damn; I'm away from this list for a couple of days, and y'all somehow
sense it, don't you?  Oy.

I'm responding to a message by Scott, because there are some things I
want to say to Scott and specifically in response to this.  But the
points below about how we should and shouldn't be arguing things are
ones that apply to others as well.

> (believe it or not) I am trying to minimize how much I repeat myself.

Scott, be assured that your comments are being paid attention to --
the comments on the spec, the comments on the proposed charter, and
the comments about the process we're following.

> To my knowledge, there have been less than a handful of reviews

Yes; as I've said, I want to see more reviews, and I want to see
reviewers comment specifically on the process.

> are unlikely to be needed,

Good, thanks; that's useful to know.

> but that doesn't mean the document doesn't need significant work.

The question I have about this is whether you think the significant
work really needs a working group to do it, or whether it can be
handled by the individual submission path.  The document editors will
address your comments, there will be other reviews, and in the end we
will either end up with a standards-track document that we have rough
consensus on... or with a decision to abandon it.

I think that can be done as an individual submission, but I'm willing
to be convinced that that's not correct.

> Secret group isn't a "jab".  It's a fact.

Well, it's closed, but it's not secret.  In any case, let's all do our
best to avoid that kind of rhetoric.  The DMARC proponents
participating here are well aware that they can't use "We developed it
over there," as a claim to consensus, and I don't think they're trying
to.  Hence, see above about more reviews.

> the group do some serious work on improving the base spec makes sense

Thank you; this, too, is useful.  And as I said above, I hear you and
Pete hears you.  Your comments are being paid attention to.

> think I'm likely to change anyone's mind at this point

Well, I think the important point is that if you have something new to
say, please say it.  If you've already made your point, we've heard
it, and thanks for that.

Barry, Applications AD

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 25 Jul 2013 12:31:20 -0400

On Thursday, July 25, 2013 11:34:49 AM Barry Leiba wrote:
> > That said, I agree with the general premise that changes to bits on the
> > wire are unlikely to be needed,
> 

What I meant to say is that the discussions are secret, the existence of the 
group is, of course, well known.

> > If I start with the assumption that this is the correct approach, then I
> > don't think an IETF working group to write a BCP makes sense.  I still
> > think having the group do some serious work on improving the base spec
> > makes sense
> > I think I'm just going to sit out further charter discussions because I
> > don't think I'm likely to change anyone's mind at this point
> 

Thanks.  I think I've made it.

Scott K

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 25 Jul 2013 16:59:21 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Scott Kitterman
> Sent: Thursday, July 25, 2013 12:31 PM
> To: [email-masked]
> Subject: Re: [dmarc-ietf] Updated Draft Charter for Review
> 
> > >> The proposal of working on the document as an Individual Submission
> > >> does not mean it is immutable.  It will go through an IETF Last
> > >> Call just like any other, and it will be required to accommodate
> > >> any sustained feedback received.
> > >
> > > That said, I agree with the general premise that changes to bits on
> > > the wire are unlikely to be needed,
> >

I much prefer the word private over the word secret. I'm not sure what your point is regarding such discussions. Are you asserting that participants in IETF working groups never have side bar conversations? Are you willing to assert that you have never had a side bar "private" conversation with anyone about a topic or issue before an IETF working group?

Unless you have evidence that this group engaged in private discussions are secretly trying to manipulate the IETF process in nefarious ways then I don't see how the existence of this private group makes any difference. The group has been public and forthright about concerns as well as process. 

In order for your expressed concern to be relevant you need to provide some evidence that the group is subverting the IETF rather than working within the existing mechanisms/processes. The choice to pursue individual submission may not be your preference but that is a legitimate approach. I haven't seen a substantive argument from you with regard to private discussions.

> > > base spec makes sense
> > > I think I'm just going to sit out further charter discussions
> > > because I don't think I'm likely to change anyone's mind at this
> > > point
> >

Mike

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 25 Jul 2013 14:12:48 -0400

On Thursday, July 25, 2013 04:59:21 PM MH Michael Hammer wrote:
> > What I meant to say is that the discussions are secret, the existence of
> > the group is, of course, well known.
> >
> > 
> 
> I much prefer the word private over the word secret. I'm not sure what your
> point is regarding such discussions. Are you asserting that participants in
> IETF working groups never have side bar conversations? Are you willing to
> assert that you have never had a side bar "private" conversation with
> anyone about a topic or issue before an IETF working group?
> 
> Unless you have evidence that this group engaged in private discussions are
> secretly trying to manipulate the IETF process in nefarious ways then I
> don't see how the existence of this private group makes any difference. The
> group has been public and forthright about concerns as well as process. 
> 
> In order for your expressed concern to be relevant you need to provide some
> evidence that the group is subverting the IETF rather than working within
> the existing mechanisms/processes. The choice to pursue individual
> submission may not be your preference but that is a legitimate approach. I
> haven't seen a substantive argument from you with regard to private
> discussions.

Of course side discussions happen all the time.  

I don't think it's nefarious, but it's not open.  The "normal" IETF process in 
my experience is that the primary venue for discussions and decision making 
are open and there are some side discussions along the way.  So far, DMARC has 
been the opposite.  From an outside perspective, drafts come out, comments go 
in, and then another draft comes out.

In the most recent draft some of my comments against earlier drafts have been 
partially addressed.  There wasn't any public discussion of the proposed 
changes, they just appear out of nowhere.  

I'm not claiming my comments are being ignored, I know they aren't.  I would 
like for there to be an open venue to discuss and resolve the issues that come 
up when people review the drafts.  

I don't need to prove nefariousness and I'm not claiming there's some rule 
violation associated with an AD sponsored individual submission.  I'm not 
concerned that the DMARC group is up to no good.  I'm concerned that the 
resistance to open work on the base spec is going to produce a lower quality 
result.  Obviously the AD can decide to do this however he wants.  I'm arguing 
for the one that I think will work the best.

Scott K

---

From: Barry Leiba <[email-masked]>
Date: Thu, 25 Jul 2013 14:20:12 -0400

> up when people review the drafts.

And this is that venue.

Let's take this message as my request that the DMARC community keep
all discussion of the DMARC specification on this list
([email-masked]) while we are processing the document in the IETF.
(This isn't an accusation, and there's no particular need to have a
meta-discussion here.  Let's just make sure the discussions of the
spec happen here.)

Barry, Applications AD

---

From: "Jones, Steven M" <[email-masked]>
Date: Thu, 25 Jul 2013 21:19:54 +0000

> Damn; I'm away from this list for a couple of days, and y'all somehow

This is similar to how I have felt about all of these threads - when I can make some time to catch up on them, I often feel like the atmosphere is so charged that any comments I might make would not be productive. But thank you for returning and reminding us that all voices both deserve to be heard, are in fact being heard, and will be considered.

Thanks in no small part to the recent edits, the charter seems reasonable to me. I plan to participate remotely in the BoF, and hope to participate in the proposed working group when it is instantiated.

I think trying to address "display name" and mailing list transits could be another 3 year slog, but an attempt - here or elsewhere - needs to be made. These problems haven't gone away on their own, and I guess in this case past performance does guarantee future returns... ;)

--Steve.

----------------------------------------------------------------------
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer.   If you are not the intended recipient, please delete this message.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 25 Jul 2013 14:23:02 -0700

> in, and then another draft comes out.

As I've said before, this is not true.  The private group went public via a
web site and simultaneously created an open list for discussion, to which
you subscribed and on which you participated in discussions about the
document once it went public.  That happened in January of 2012.  Other
than the fact that said list was not an @ietf.org list, it doesn't get much
more open and relevant than that.

> changes, they just appear out of nowhere.

As is typical in IETF processing (to which you've had plenty of exposure),
changes that are obviously right often don't get large amounts of
discussion before they appear in documents.  I don't know why this is
suddenly noteworthy.

If there are bits you mentioned on-list that were missed in the update,
then by all means please identify them and describe the remedy you'd like
to see, preferably with OLD/NEW text as usual.

> up when people review the drafts.

Such has existed for over 18 months now, and recently this additional one
has appeared.

> for the one that I think will work the best.

I totally agree, but I also believe that these discussions about abnormal,
closed, or private discussions are a distraction at best.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Fri, 26 Jul 2013 06:43:24 +0100

On 7/25/2013 10:19 PM,, Steven M wrote:
> I think trying to address "display name" and mailing list transits could be another 3 year slog, but an attempt - here or elsewhere - needs to be made. These problems haven't gone away on their own, and I guess in this case past performance does guarantee future returns...;)

It might help for us to try to find reasonable wording for the goal we 
think reasonable, concerning display names.  I think it's easy to make a 
lofty, appealing goal statement, but probably much harder to make a 
pragmatic one that folks generally think technically and operationally 
and socially tractable.

In fact I think it daunting enough that -- contrary to my usual practice 
when suggesting a group pursue wording -- I can't think of candidate 
text to offer.

d/