Subject: [spfbis] I-D Action: draft-ietf-spfbis-experiment-01.txt

From: [email-masked]
Date: Tue, 10 Apr 2012 21:19:39 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SPF Update Working Group of the IETF.

	Title           : Resolution of The SPF/Sender-ID Experiment
	Author(s)       : Murray S. Kucherawy
	Filename        : draft-ietf-spfbis-experiment-01.txt
	Pages           : 10
	Date            : 2012-04-10

   In 2006 the IETF published a suite of protocol documents comprising
   SPF and Sender-ID, two proposed email authentication protocols.
   Because of interoperability concerns created by simultaneous use of
   the two protocols by a receiver, and some concerns with Sender-ID and
   compatibility with existing standards, the IESG required them to have
   Experimental status and invited the community to observe their
   deployments for a period of time, hoping convergence would be
   possible later.

   After six years, sufficient experience and evidence have been
   collected that the experiment thus created can be considered
   concluded, and a single protocol can be advanced.  This memo presents
   those findings.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-spfbis-experiment-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-spfbis-experiment-01.txt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Apr 2012 04:32:33 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Tuesday, April 10, 2012 9:20 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [spfbis] I-D Action: draft-ietf-spfbis-experiment-01.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the SPF Update Working Group
> of the IETF.
> 

The update includes a general update of recent data collections, including a re-run of Philip's survey, the addition of one of Hotmail's surveys, and an update to mine.  I also added a snapshot of the SUBMITTER survey results, and added some SUBMITTER use information from McAfee.

At this point I'm expecting some data from Hotmail late this month, and I can keep checking on the SUBMITTER survey and my own SPF record survey, but I don't anticipate any of the current text to change much as a result.  So unless there are other data sets that we should go get or that people want to submit, I think we're close to done.

Rather than simply waiting for all of those pending results to come in, I suggest we start talking about the text, i.e., people should review it and comment.

Or have we done enough due diligence on both text and data to ask the co-chairs for a Working Group Last Call already?  :-)

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Tue, 10 Apr 2012 23:56:13 -0700

Hi Murray,
At 21:32 10-04-2012, Murray S. Kucherawy wrote:
>Or have we done enough due diligence on both text and data to ask 
>the co-chairs for a Working Group Last Call already?  :-)

There is a "SHOULD" and a "MUST" in Appendix A which got flagged 
because of RFC 2119.  I ignored the nit in an unrelated draft.

I'll discuss with Andrew about the Working Group Last Call.  I'll 
leave it to the Responsible AD to determine whether this working 
group have done enough due diligence in producing the first deliverable. :-)

Regards,
S. Moonesamy

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Apr 2012 07:04:16 +0000

> From: S Moonesamy [mailto:[email-masked]]
> Sent: Tuesday, April 10, 2012 11:56 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-01.txt
> 

The idnits check didn't throw an alarm.  What was the flag?  Or are you talking about your own review?

It's a citation of other normative text, but is not itself normative.  That's not something we can catch automatically, I imagine.

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Wed, 11 Apr 2012 00:30:44 -0700

Hi Murray,
>you talking about your own review?

The following is from Id-nits [1]:

  "RFC 2119 keyword, line 358: '...       SHOULD publish both types and M...'"

>It's a citation of other normative text, but is not itself 
>normative.  That's not something we can catch automatically, I imagine.

Yes.  I wouldn't worry about it.  I mentioned it in case the question comes up.

Regards,
S. Moonesamy

1. 
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-spfbis-experiment-01.txt

---

From: Hector Santos <[email-masked]>
Date: Wed, 11 Apr 2012 06:16:43 -0400

The entire section 2 of the Interop report, and specifically the last 
paragraph

    2.  The Need For Consensus

    These two protocols fall into a family of protocols that provide
    domain-level email authentication services.  For reference, another
    prominent one is [DKIM].  Various efforts exist that use these as
    building blocks to increased abuse filtering capabilities, and indeed
    this sort of work has spawned another working group in the
    Applications area, with still more of these incubating in
    associations and trade groups outside of the IETF.

    There is thus some palpable interest in having a path authorization
    scheme, as well as a domain-level signing scheme, on the Standards
    Track so that these newer technologies can develop with confidence.
    This is, in part, why the community has decided to expend the effort
    to bring this experiment to a conclusion and document the results,
    and then advance a single path authorization technology.

I believe this section 2 should be removed in its entirety.

Reasons:

Section 2 is *NOT* a SPFBIS charter consideration. DKIM is not a 
consideration for SPFBIS, nor was it the main interest of the SPFBIF 
group. While the editor admits it was his reason for starting the 
group, the editor neglects it was not one of the 2006 IETF 
considerations for initiating  SPF, SENDERID experiment to explore the 
coexistence of both protocols.  In fact, the proposed CSV/DNA, 
Domainkeys and IM, and DKIM by virtue of DKEYS/IM eventual merged 
protocols where specifically voted out and tossed out as MARID 
workgroup products to consider.

-- 
Hector Santos, CTO
http://www.santronics.com
http://hector.wildcatblog.com

---

From: Hector Santos <[email-masked]>
Date: Wed, 11 Apr 2012 06:50:00 -0400

Two comments;

1) In section 5.2, item 3

   3.  that the absence of significant adoption of the type 99 DNS
        resource record, the [SUBMITTER] extension, [SENDER-ID], and
        [PRA], indicates that they are de facto obsolete.

More of a nit, I recommend the two itemized recommendations to be 
split as #3 and #4.  The two stated recommendations are two completely 
different non-related recommendations where current implementations 
will most likely consider separated.

2) What does "de facto obsolete" mean?

This is a slippery slope problem which quite honestly is not the main 
issue but rather it comes of the expense of a lack of understanding 
what the PRA presented and the data has always shown.

In short, the PRA was not expected be dominant. It was not suppose to 
be an Alternative solution to SPF.  The PRA simply presented an 
algorithm to reflect the possible use cases where a 3rd domain 
identity in RFC2822 may exist.  It was NOT suppose to be the dominant 
use case and it was well established it would a offer a low percentage 
around. By my estimates ~15%.

The RFC4407 PRA algorithm specifically has it so that the fallback 
domains would be the same SPF domains to evaluate.  IOW, outside the 
specific use cases, over 80% of the time, the SPF domains in the 
5321/5322 transaction would be the same:

    PRA === 5322.From Domain === 5322.Sender Domain === 5321.MAIL FROM 
domain

So IMO, the Interop report would be in error to use expected 
measurements of a low ~15% to suggest it reflects lack of usage or "de 
fauto obsolete" usage.

---

From: S Moonesamy <[email-masked]>
Date: Tue, 17 Apr 2012 02:29:01 -0700

>2) What does "de facto obsolete" mean?

 From an IETF perspective, I read it as: RFC 4405, 4406 and 4407 are 
viewed as obsolete in practice.  draft-ietf-spfbis-experiment-03, as 
it stands, is not a formal action to change the status of those three 
RFCs.  If this WG was requesting such an action, it would have added 
an "Obsoletes:" tag at the top of Page 1 of the 
draft-ietf-spfbis-experiment-03.

RFC 2821 is supported by Microsoft Exchange Server 2010.  That RFC 
was obsoleted by RFC 5321 in October 2008.  According to the current 
Exim documentation, Exim implements RFC 2554.  That RFC was obsoleted 
by RFC 4954 in July 2007.  The current Postfix documentation refers 
to RFC 2821.  If I have to send an email to hotmail.com, my mail 
server must adhere to RFC 2821 and RFC 2822.  RFC 2822 was obsoleted 
by RFC 5322 in October 2008.

Regards,
S. Moonesamy

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 17 Apr 2012 15:24:53 +0200

On Tue 17/Apr/2012 15:08:03 +0200 S Moonesamy wrote:
> From an IETF perspective, I read it as: RFC 4405, 4406 and 4407 are viewed as
> obsolete in practice.  draft-ietf-spfbis-experiment-03, as it stands, is not
> a formal action to change the status of those three RFCs.  If this WG was
> requesting such an action, it would have added an "Obsoletes:" tag at the top
> of Page 1 of the draft-ietf-spfbis-experiment-03.

Right.  Then, I'd support removing Sender-ID stuff from that paragraph.
Indeed, we don't /need/ to recommend to the IESG that "the [SUBMITTER]
extension, [SENDER-ID], and [PRA], indicates that they are de facto obsolete."

I'd rather reformulate point 3 to stress the DNS question, possibly
summarizing the recommendations that emerged from the relevant ietf list
thread ("provisioning software, was DNS RRTYPEs, the difficulty with"), and
making it clear that accusations of spurious DNS usage are moot until they
won't have been addressed.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 17 Apr 2012 16:09:36 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Tuesday, April 17, 2012 6:25 AM
> To: [email-masked]
> Subject: Re: [spfbis] draft-ietf-spfbis-experiment-01 issue: section 5.2 Item 3 recommendation to split
> 
> > an "Obsoletes:" tag at the top of Page 1 of the draft-ietf-spfbis-
> > experiment-03.
> 
> summarizing the recommendations that emerged from the relevant ietf
> list thread ("provisioning software, was DNS RRTYPEs, the difficulty
> with"), and making it clear that accusations of spurious DNS usage are
> moot until they won't have been addressed.

I don't agree.  What we're trying to resolve here is which of the two protocols the community wants to advance to the standards track, leaving one behind, thus concluding the experiment.  If we omit that, we haven't actually met our first deliverable.

The DNS RRtype question is a relevant part of the question, but not all of it.

The term "de facto obsolete" means, quite literally, "from the facts, obsolete".  The dictionary defines "obsolete" as "no longer in general use; fallen into disuse".

So, based on the data collected and presented in the document, which nobody has challenged yet in terms of either methods or content, the expression is quite appropriate.

As SM also points out, this document doesn't change the status of the three documents.  That's for us to decide to do (or not) in the other document.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 17 Apr 2012 16:26:23 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
> Sent: Tuesday, April 17, 2012 9:10 AM
> To: [email-masked]
> As SM also points out, this document doesn't change the status of the
> three documents.  That's for us to decide to do (or not) in the other
> document.

...although if we want RFC4408bis itself to be completely SIDF-agnostic, perhaps we should consider the status change actions for inclusion in this document.

Opinions?

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 17 Apr 2012 18:46:33 +0200

On Tue 17/Apr/2012 18:35:28 +0200 Murray S. Kucherawy wrote:
> 
> What we're trying to resolve here is which of the two protocols the
> community wants to advance to the standards track, leaving one behind,
> thus concluding the experiment.  If we omit that, we haven't actually met
> our first deliverable.

That's not quite what the charter says, though.  We cannot opt to advance
Sender-ID instead.

> The DNS RRtype question is a relevant part of the question, but not all of

I'd split that point in any case, because they are two unrelated questions.

> The term "de facto obsolete" means, quite literally, "from the facts,
> obsolete".  The dictionary defines "obsolete" as "no longer in general
> use; fallen into disuse".
> 
> So, based on the data collected and presented in the document, which
> nobody has challenged yet in terms of either methods or content, the
> expression is quite appropriate.

Yes, it is.  The point is that we don't need to change the status of those
documents, or recommend that the IESG does so, in order to advance SPF.  If
there were consensus on that, perhaps we could do it.  But given that there
doesn't seem to be consensus, it would seem easier to skip it.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 17 Apr 2012 12:56:14 -0400

On Tuesday, April 17, 2012 04:26:23 PM Murray S. Kucherawy wrote:
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Murray S. Kucherawy Sent: Tuesday, April 17, 2012 9:10 AM
> > To: [email-masked]
> ...although if we want RFC4408bis itself to be completely SIDF-agnostic,
> perhaps we should consider the status change actions for inclusion in this
> document.
> 
> Opinions?

I would strongly prefer that 4408bis not change the status of 4405 - 7.  I 
don't believe it's necessary for this working group to change the status of 
those documents to do it's work.  We are documenting the result of an 
experiment and developing 4408bis to move SPF from experimental to standards 
track.  That's it.

As a definition of the experimental protocol, I think 4405 - 7 are fine.  They 
document it correctly.  At some point it will be appropriate to mark them all 
historic.  I don't think it is necessary for us to get distracted with a 
discussion about how dead they need to be to do that.

Scott K

---

From: Dotzero <[email-masked]>
Date: Tue, 17 Apr 2012 12:59:24 -0400

> ...although if we want RFC4408bis itself to be completely SIDF-agnostic, perhaps we should consider the status change actions for inclusion in this document.

I personally think the best course of action is to ignore the 3 SIDF
documents. RFC4408 does not address them and neither should 4408bis.
If others wish to take up those documents to either get them marked
historic or to update them in an attempt to go standards track then
that is up to them.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 17 Apr 2012 17:01:02 +0000

> Sent: Tuesday, April 17, 2012 9:47 AM
> To: [email-masked]

I don't see what clarity this change adds to the document, so I still disagree.  Any other opinions?

> Yes, it is.  The point is that we don't need to change the status of
> those documents, or recommend that the IESG does so, in order to
> advance SPF.  If there were consensus on that, perhaps we could do it.
> But given that there doesn't seem to be consensus, it would seem easier
> to skip it.

The recommendation to the IESG to consider them obsolete is not itself a document action.  It's merely a conclusion based on the data.

As SM pointed out, the current version of the experiment document doesn't change the status of the other documents.  It could, if that's what we think it should do, especially if we think RFC4408bis itself should not do so.  I posed that question in my last message.
 
Personally, I think one of our two deliverables needs to take that action.  The IESG Note included at the top of the original four documents makes it clear that the IESG (at least, the one seated back then) didn't like the idea of them coexisting since they share policy data but apply different algorithms.  It seems to me the resolution of that point doesn't leave us many options.  So really the only question to me is which of the two documents should do it, and whether we want to do "obsolete", or both "obsolete" and "historic".

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 17 Apr 2012 17:01:52 +0000

> From: Dotzero [mailto:[email-masked]]
> Sent: Tuesday, April 17, 2012 9:59 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> documents. [...]

Ignore them in RFC4408bis, or in both that and the experiment document?

---

From: Hector Santos <[email-masked]>
Date: Tue, 17 Apr 2012 13:05:49 -0400

Murray S. Kucherawy wrote:
> So, based on the data collected and presented in the document, 
> which nobody has challenged yet in terms of either methods or 
> content, the expression is quite appropriate.

Its not appropriate because its applied incorrectly. Does it imply?

   1. SenderID is no longer considered by vendors?

   2. It its no longer offered as an option in vendor software? i.e.
      operators no longer have the option to enable it?

   3. It was unofficially deprecated long ago and now can be
      considered obsolete?

   4. A Low Usage Threshold, very subjective, justifies a
      classification of obsolete?

A key point is #4 because the SenderID Framework inherently only 
considered certain limited uses cases and it was long pointed out 
since 2006 that statistically over 80% of the transaction, it didn't 
apply. All the domains matched:

    PRA.domain = 5321.MAILFROM.domain = 5322.FROM.domain

and this is reflective with SUBMITTER

    PRA.domain = 5321.MAILFROM.domain = 5322.FROM.domain = 
5321.SUBMITTER.domain

It was all part of showing that PRA consideration came a more 
PAYLOAD/DNS price 80% of the time, especially in the early initial 
deployment era when blind DNS lookups and a logical expectation for a 
very high waste in NXDOMAIN results.

So is your conclusion based on the 20% possible spectrum of use cases 
is not an appropriate consideration? That the PRA proposal of that 3rd 
identity was invalid and incorrect and therefore allows the IETF the 
engineering affordability and perspective to recommend its no longer a 
consideration and therefore obsolete?

The reality in practice is that is not obsolete. It is in play, it is 
still used and we know we can measure at least one part of the 
population with the significant volume of SUBMITTER clients.  And if 
its not already understood, a compliant client MUST use the MAIL FROM 
SUBMITTER= attribute, even when the 80% of the time they are the same 
as 5321.MAIL FROM domain.

I believe these comments are valid technical challenges to the 
assertion the protocols are by "de facto" obsolete.

---

From: Dotzero <[email-masked]>
Date: Tue, 17 Apr 2012 13:15:29 -0400

> Ignore them in RFC4408bis, or in both that and the experiment document?

Ignore them (or any parts which some have proposed including) in RFC4408bis.

As long as the experiment document is descriptive (not prescriptive) I
don't have any objections to an examination of SIDF implementation as
part of that document.

---

From: Hector Santos <[email-masked]>
Date: Tue, 17 Apr 2012 13:20:15 -0400

> historic or to update them in an attempt to go standards track then

+1,

If SPFBIS is not interested in a total SPF framework solution that 
benefits all and can't afford or has the desire to review in earnest 
the SenderID Framework (SIDF), then its should not be making any 
subjective conclusions on the SIDF.

Allow another "SIDF-BIS" WG to look at the 6+ years of integrated 
experiences,  review its original purpose and problem solving idea, 
see what payoff the PRA brought, review the documented use cases and 
also see if they still valid today and if deemed worthy to move it 
forward to IS, clean it up and make any corrections of the cited 
conflicts with SPFBIS, if any.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 17 Apr 2012 17:31:59 +0000

> Sent: Tuesday, April 17, 2012 10:15 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]

OK that part's clear.

> don't have any objections to an examination of SIDF implementation as

I'm still not clear here.  The question is: Do we want to consider having the experiment document change the status of the Sender-ID documents?  It's already doing the examination you're talking about, but the status change question remains open.

-MSK

---

From: Dotzero <[email-masked]>
Date: Tue, 17 Apr 2012 13:36:06 -0400

> I'm still not clear here.  The question is: Do we want to consider having the experiment document change the status of the Sender-ID documents?  It's already doing the examination you're talking ab…

While I personally believe that SIDF provides little if any additional
value beyond SPF - and PRA is clearly broken - I feel it is outside of
the scope of the WG Charter to make changes to the status of the 3
SIDF RFCs - one way or the other. If it were within the WG Charter my
poersonal position would be to mark those 3 RFCs as historic.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 17 Apr 2012 17:38:02 +0000

> Sent: Tuesday, April 17, 2012 10:36 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> the scope of the WG Charter to make changes to the status of the 3 SIDF
> RFCs - one way or the other. If it were within the WG Charter my

Thanks, that's what I'm after.  And since you said RFC4408bis itself should ignore the others, then if we were to make that status change (and you felt the charter permitted such), the experiment document would be the place to do it?

---

From: Dotzero <[email-masked]>
Date: Tue, 17 Apr 2012 13:45:34 -0400

> Thanks, that's what I'm after.  And since you said RFC4408bis itself should ignore the others, then if we were to make that status change (and you felt the charter permitted such), the experiment d…

I've already indicated that I believe this is outside the WG charter.
I've already indicated my belief that "fixing"/moving 4405-7 to
standards track is outside the scope of the WG charter. This would
leave marking them historic. I don't know what the process is for
that. Again though, I'd prefer to let sleeping dogs lie and focuse on
updating 4408 and getting it on Standards track.

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Tue, 17 Apr 2012 19:56:58 +0200

> ...although if we want RFC4408bis itself to be completely SIDF-agnostic, perhaps we should consider the status change actions for inclusion in this document.

Another option is, similar to what happened with 4870 and 4871: publish 
a set of four new documents, where the 4405bis, 4406bis and 4407bis 
documents all get:

Obsoleted By: RFC4408bis
Category: Historic

This way, the SPFBIS charter is not violated, in my opinion, as it states:

    The group will complete additional work on SPF
           (described below), but will not complete additional work on the
           Sender-ID specification.

By publishing the SIDFbis documents as obsoleted/historic, no additional 
work has been done on the Sender-ID specification.

If the SIDF documents are not declared historic/obsoleted, the 
conflicting interests of SPF and Sender-ID with respect to the use of 
the DNS records is not resolved and it may not be able to advance SPF as 
standards track document.

/rolf

---

From: "John Levine" <[email-masked]>
Date: 17 Apr 2012 18:38:37 -0000

>standards track document.

This seems exceedingly unlikely unless our ADs are a lot dimmer than
I think they are.  We all know that there's no practical problem.

If it's OK with the IESG for the experiment report to reclassify 4405
through 4407 as historic, that would be a reasonable thing to do.  Or
failing that, someone could do one-page independent submission similar
to RFC 6547 that just notes that they're historic now.  But it's not
urgent.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 17 Apr 2012 18:47:57 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of John Levine
> Sent: Tuesday, April 17, 2012 11:39 AM
> To: [email-masked]
> Cc: [email-masked]

On the other hand, given the text of the IESG Note in those RFCs, they might ask why we didn't.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 17 Apr 2012 19:20:21 -0000

>On the other hand, given the text of the IESG Note in those RFCs, they might ask why we didn't.

Perhaps we could ask our AD to inquire whether it'd be OK for the
experiment report to do the reclassification.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Tue, 17 Apr 2012 15:48:53 -0400

Dotzero wrote:

>> Thanks, that's what I'm after. �And since you said RFC4408bis itself should ignore the others, then if we were to make that status change (and you felt the charter permitted such), the experiment document would be the place to do it?
>>
>>
> 
> leave marking them historic. 

IMV, it doesn't seem proper to make any status changes, including one 
to Historic. If its not prepared to do a thorough technical review of 
all the 6+ years experimentation of the SPF/SenderID Framework as 
recommended by the IESG either as separate or in tandem, then any 
decision of lieu of a real review, conflicts with its declared out of 
scope status.

---

From: S Moonesamy <[email-masked]>
Date: Tue, 17 Apr 2012 12:48:52 -0700

>experiment report to do the reclassification.

http://www.ietf.org/mail-archive/web/spfbis/current/msg00331.html

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 17 Apr 2012 16:01:11 -0400

> http://www.ietf.org/mail-archive/web/spfbis/current/msg00331.html
So if they complain we didn't obsolete the Sender ID RFCs we can tell them 
they should have given us a better charter.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 17 Apr 2012 20:04:13 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Tuesday, April 17, 2012 1:01 PM
> To: [email-masked]
> So if they complain we didn't obsolete the Sender ID RFCs we can tell
> them they should have given us a better charter.

I'm pretty sure that, to tie up this loose end as Dave suggests:

a) The IESG could decide to do so on its own based on our document(s), without us actually saying so; or

b) We could make the request to the IESG without an accompanying document; or

c) An individual could make such a request.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Tue, 17 Apr 2012 16:24:21 -0400

> On the other hand, given the text of the IESG Note in those RFCs, they might 

Or they may ask or is asked they consider why the cited conflicts, if 
it actually existed and provided serious conflicts,  were not resolved?

I don't agree it was just a "Select One or other" consideration, but 
also how they could coexist in tandem:

    The IESG takes no position about which approach is to be preferred
    and cautions the reader that there are serious open issues for each
    approach and concerns about using them in tandem.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 17 Apr 2012 13:26:23 -0700

> I'm pretty sure that, to tie up this loose end as Dave suggests:
...
> b) We could make the request to the IESG without an accompanying document; or

While they will, no doubt, need some sort of document draft to refer to 
for this, it doesn't need to get published.  A one-page I-D with the 
recommendation is probably enough.

In any event, your b) path is the direction I'm thinking is sufficient.

d/

-- 
  Dave Crocker
  bbiw.net