Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06

From: Alessandro Vesely <[email-masked]>
Date: Sat, 01 Sep 2012 19:04:44 +0200

On Sat 01/Sep/2012 05:26:34 +0200 Murray S. Kucherawy wrote:
> On Fri, Aug 31, 2012 at 6:23 PM, S Moonesamy <[email-masked]> wrote:
>> [At 17:54 31-08-2012, Murray S. Kucherawy wrote:]
>>> Perhaps the simplest thing to do is to start an individual submission
>>> to collect this stuff, and move it out of here.

+1

>>> The trick, though, is that RFC4408bis itself should then refer
>>> to it, which will delay its publication until that document
>>> finds a new home or an AD sponsor and is also published.

Isn't it possible to just mention "an applicability statement to be
published next" sort of thing?  Part two will then refer to RFC4408bis.

>>> (And I can tell you that we're very unlikely to take it in
>>> APPSAWG.)
>>
>> I don't know what to suggest.  I won't suggest APPSAWG. :-)
> 
> The APPSAWG co-chair thanks you.  (Seriously, though, there are
> several procedural things blocking that path.)

+1 (as APPSAWG participant)

> If we do split the work in this way, we technically still hit our
> deliverable even if it lands in the RFC Editor queue and stalls there
> until the second document finishes via whatever path is chosen for it.

Rechartering is the best way, IMHO.

>  We just have to accept the unpredictable delay.  The only work then
> is to decide what parts of the current Section 9 are required to make
> the document whole (those should stay) and which constitute
> non-critical implementation advice (those should move).
> 
> It's possible that new content from other sections is also a candidate
> for such a migration, which would make Arthur happy.

Yes, I don't think splitting the document is a silly idea.  Indeed, it
reflects the "second life" of SPF pretty well.  While some parts of
Section 9 are almost fine where they are, any rejection-related advice
should be moved to part two, possibly including the exp= modifier.

> Oh, and you need to find an editor(s).  ;-)

May I volunteer for that?

---

From: S Moonesamy <[email-masked]>
Date: Sat, 01 Sep 2012 11:17:12 -0700

Hi Alessandro,
>May I volunteer for that?

Yes, if there was a WG draft. :-)  There wasn't much enthusiasm to 
work in such an I-D when the question came up.  There is nothing 
stopping you from submitting an I-D.  I'll ask for it not to be 
discussed on this mailing list as the working group is working on 
draft-ietf-spfbis-4408bis.

Regards,
S. Moonesamy

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 02 Sep 2012 14:17:12 +0200

Hi SM and All,

On Sat 01/Sep/2012 20:17:12 +0200 S Moonesamy wrote:
> stopping you from submitting an I-D.

I had considered the possibility to submit a new I-D a few days before
this thread began [28].  Then, this possibility resurfaced with this
thread, superseding my earlier intention.  So I'd need some more
encouragement than that in order to go ahead and write it.
[28] http://www.ietf.org/mail-archive/web/spfbis/current/msg02414.html

> I'll ask for it not to be discussed on this mailing list as the
> working group is working on draft-ietf-spfbis-4408bis.

The new I-D and draft-ietf-spfbis-4408bis will depend on one another,
since we consider moving some parts, such as sections 6.2 and 9.2,
from one document to the other.  That requires rough WG consensus.
I'd imagine the procedure to reach it would go as steps 1-7 below
(please correct me as necessary):

1  Someone prepares the new I-D and submits it,

2  WG participants look at it, then

3  WG participants agree on the split.

Those three steps will consume some discussion resources on this list.
 It can be easily anticipated that discussing the split will naturally
result in discussing some of the new I-D's details.  Such items are to
be saved for a later stage, but they will unavoidably consume some
more discussion resource as they emerge.

Then, assuming 1, 2, and 3 succeeded:

4  The new I-D is registered as a WG I-D,

5  duplicated parts are removed from draft-ietf-spfbis-4408bis,

6  rechartering process gets started, and

7  draft-ietf-spfbis-4408bis undergoes WGLC and IESG submission.

I volunteered for editing the new I-D because I envision it as a much
awaited clarification of receiver behavior:  An applicability
statement that specifies how a server may reject mail that is
definitely abusive, based on the SPF results obtained during the
earlier stages of an SMTP transaction.  The purpose is to save the
server's resources without disrupting the mail flow.  It can stick to
the original SPF catch, "you have to register a domain before you
transmit DATA", taking into account also non-rewriting forwarders.

While that obviously needs rechartering, step 5 above does not, since
receiver behavior was never 2119-wise specified.  However, some
confidence about the fate of the new I-D --see steps 4 and 6-- is
requisite in order to seriously consider step 5.

OTOH, if there is still not much enthusiasm, please let's drop the
idea of moving Section 9 for good, and have Scott post -07.

---

From: Hector Santos <[email-masked]>
Date: Sun, 02 Sep 2012 10:57:43 -0400

Hi Alessandro,

As an early system integrator and adopter of most email security 
related methods, protocols, experimental, standards, pilots, etc, I 
have long sought an ideal completion of the SPF "experiment" work to 
not only finally IETF standardize the protocol but to incorporate 
integrated related technologies that were learned, evolved and matured 
over the years.   I firmly believe it can be done from a cooperative 
competition stand point where the IETF community benefits, accepted 
"chartered" work items can be completed and foremost, its done with 
little to no impact, "No Surprises" with backward compatibility.  When 
one puts engineering trust on their industry peers who is able to do 
the work and documentation, there should be no losers except the 
problem it addresses.

Unfortunately, as I cited in an April or earlier list post during the 
original charter revision discussions, repeated during the IETF83 SPF 
meeting jabber session, and now you reminded me here with your statement:

    "The new I-D and draft-ietf-spfbis-4408bis will depend on one another,
    since we consider moving some parts, such as sections 6.2 and 9.2,
    from one document to the other." [1]

My main concern was basically how a fast track I-D, presumingly only 
possible as a BCP or Informational status RFC, could be used to 
redefine the charter, scope of the work, framework of the work, by 
promoting certain deployments that is not considered ideal or better 
universal for SPF operations.  In this case I cited:

    "While I not at all adverse to good solid integrated designs, the 
concern
     was how it change the SPFBIS WG focus towards MARKING instead of 
REJECTION
     for FAIL policy results." [2]

In other words, controversial ideas and methods can be embedded into 
WG work that are technically out side the work scope defined by the 
charter.

The IETF83 SPF jabber session response to my channeled voice concern 
stated it is a recognized WGC management problem and it would watched 
and not intentionally allowed to all. I accepted this response.  Refer 
to the actual phrased chair response [3] to the concern in the jabber 
audio (I seem to recall it wasn't scribed in the log).

I agreed that it is a management problem, however, I had a concern it 
has become a recent trend to change a charter direction or get around 
controversial issues hence why I cited the concern.

As long as it is consistent and persistent with the charter, does not 
open loopholes, back door methods to introduce specific methods and/or 
get around recommended methods in the main WG work product, etc, 
overall, "NO SURPRISES!" then IMO, I think it can work.

But then again, to me, what will you write about?  Do you have an 
ideal of an outline and purpose of such an I-D?  How far does it go?

I personally believe only 2.5.4 needs to be rewritten. We don't need 
section 7 or 9.

-- 
HLS

[1] SPF split and rechartering...
     http://www.ietf.org/mail-archive/web/spfbis/current/msg02568.html

[2] Hector Santos follow up correction to IETFi83 SPF minutes notes
     http://www.ietf.org/mail-archive/web/spfbis/current/msg01408.html

[3] IETF83 SPFBIS Session Audio Recording
     http://www.ietf.org/audio/ietf83/ietf83-252a-20120330-0855-am.mp3

---

From: S Moonesamy <[email-masked]>
Date: Sun, 02 Sep 2012 08:17:59 -0700

Hi Scott,

Sorry, that sounded a bit too authoritarian.  Your earlier comment is 
interesting.  I never thought of the charter meaning that.  Let me 
think about that and confer with my co-chair, but initially I don't 
think  moving a section around is a big deal.  I'll consider your 
comment and get back to you."

Regards,
S. Moonesamy

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 2 Sep 2012 11:45:26 -0700

On Fri, Aug 31, 2012 at 10:35 PM, Scott Kitterman <[email-masked]> wrote:
> The charter says:
>
>> Changes to the SPF specification will be limited to the correction
>> of errors, removal of unused features, addition of any enhancements
>> that have already gained widespread support, and addition of
>> clarifying language.
>
> Moving section 9 to an appendix is none of those things.

Here's a monkey wrench for that logic: Section 9, as it is explicitly
non-normative, doesn't actually specify anything.  Thus, rewriting,
extending, removing, or repositioning it is not a change to "the SPF
specification".

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 2 Sep 2012 20:26:21 -0700

>> May I volunteer for that?

Whoa, let's not get ahead of ourselves here.

I almost regret suggesting it for fear of distracting us from
finishing rfc4408bis itself.  But then, if there are solid concerns
about the volume of added text and questions about why certain things
were there in the first place, this is one way out of that mess.  It's
up to the co-chairs; it was only a procedural suggestion.

Let's not start jockeying for position before the decision is made and
a path forward is chosen.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 03 Sep 2012 01:40:07 -0400

> >>> to collect this stuff, and move it out of here.

First, IIRC we decided we'd get to the end of doing the draft and then decide 
if it needed splitting then, so I don't understand the sudden rush to judgment 
on this topic.

Second, I think it would be a mistake to make completion of the working 
group's effort contingent on completion of work we aren't chartered to do.  If 
we decide that 4408bis needs to be split, then I think we should really 
recharter to do it.

> published next" sort of thing?  Part two will then refer to RFC4408bis.

No.  Section 9 is pretty solidly intertwined in the main body in a number of 
places.  Such a document would need to have a normative reference from 4408bis 
and so they'd have to be published together.  In any case, if we rip out 
section 9 (which was in 4408) then we're outside our charter regardless of 
where we put it.  If we're going to recharter, then let's just recharter to do 
the work of the group in two documents, rather than leave it half done.

> should be moved to part two, possibly including the exp= modifier.

This makes no sense to me.  One of the hardest things for me to understand 
about splitting is how 4408bis would be complete without the receiver policy 
discussion.  We could move that back into the main part of the document, but I 
think it's better where it is.

> May I volunteer for that?

If the group's going to decide the document I've been working on should be 
split in two, then I'd prefer to keep working on both parts of it.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 03 Sep 2012 01:46:51 -0400

> idea of moving Section 9 for good, and have Scott post -07.

I am against individuals submitting I-D's that duplicate work that the WG is 
chartered to do.  We can't remove section 9 and be compliant with the charter, 
so we need to make a decision about this and get rechartered, if needed, 
before doing anything.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 03 Sep 2012 01:51:25 -0400

> comment and get back to you."

Thanks,

I don't think that moving a section around is inherently against our charter.  
I think it should be avoided because it could cause confusion.  I do feel that 
there is some difference in the semantics of a non-normative discussion in the 
body of an RFC and an appendix to the RFC, so there I think it's a bit gray.  
I do think that if we are going to undertake such reorganizations there ought 
to be some discussion about it.

I believe that removing section 9 is definitely outside the scope of our 
charter.  Part of the reason that I have taken such a strong position on this 
is that it appears to me that the direction to move it to an appendix is 
prepartory to removal and that I think we definitely cannot do.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 03 Sep 2012 01:52:36 -0400

> extending, removing, or repositioning it is not a change to "the SPF

Then I guess removing all the security considerations wouldn't be a change to 
the SPF specification either?

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 03 Sep 2012 11:58:22 +0200

> we decide that 4408bis needs to be split, then I think we should really 

Yes.  The point is that, if we delay the decision to write part two
until after part one is submitted, we won't be able to change part
one any more.  I attempted a step by step outline in a later message.

> No.  Section 9 is pretty solidly intertwined in the main body in a
> number of places.  Such a document would need to have a normative
> reference from 4408bis and so they'd have to be published
> together.

That's part of the changes to part one.  It seems not overly difficult
to me, but I'd need to actually try it in order to be sure.

> In any case, if we rip out section 9 (which was in 4408) then we're
> outside our charter regardless of where we put it.

I think Murray's monkey wrench works on that point.  We just wouldn't
want to do it unless we were preparing a better place to put it into.

> If we're going to recharter, then let's just recharter to do the
> work of the group in two documents, rather than leave it half
> done.

Yes.  It just takes time to get there, after we make that decision.

> This makes no sense to me.  One of the hardest things for me to
> understand about splitting is how 4408bis would be complete without
> the receiver policy discussion.

Part one will define the results and the algorithm to compute them.
It will also define header fields usage and the like, but nothing
about receiver behavior.

That way, part one would be the minimal amount of specification for
someone, like Yahoo!, say, who just needs SPF to comply with DMARC.
It's an annoyance to those users to have to go through the countless
advices about rejection.

> We could move that back into the main part of the document, but I 

If it stays non-normative, I agree.

In any case, I think we should remove the parts that didn't get any
deployment, such as operations that assume a specialized DNS server.

> If the group's going to decide the document I've been working on
> should be split in two, then I'd prefer to keep working on both
> parts of it.

That's fine for me, if you have the cycles.  The only point is that
it's easier for me to write a tentative split than to explain down to
an actionable level of detail why, say, we don't need forward
references from part one to part two.  Even then, it would take many
hours to complete it, more than what I'd be willing to spend for the
mere purpose of proving the concept.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 4 Sep 2012 11:46:41 -0700

> so we need to make a decision about this and get rechartered, if needed,

I don't agree with this interpretation (as I said separately), but
I've been wrong before.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 5 Sep 2012 12:43:52 -0700

> the SPF specification either?

Every RFC has to have security considerations, or it can't be
published.  And SPF has plenty to discuss in that area.  So, no.

My point is that there's so much explanatory and pedagogical text
either in RFC4408bis or being proposed for addition to it that
creating a parallel deployment guide to include all the non-critical
discussion would de-bulk the core in a useful way, and some of that
was also present in RFC4408.  That's why I suggested it.  This was a
successful tactic for other protocols that now comprise multiple
documents.  Perhaps SPF would benefit from such a division of output.

The idea is not to hide or remove material, only to arrange its
presentation differently.

Anyway, it's a suggestion for the chairs to consider.  It's their
call.  It will require a re-charter, but I suspect that request would
meet with little AD resistance should they decide to do it.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 05 Sep 2012 16:16:08 -0400

On Wednesday, September 05, 2012 12:43:52 PM Murray S. Kucherawy wrote:
> > Then I guess removing all the security considerations wouldn't be a change
> > to the SPF specification either?
> 

If we conclude a split is appropriate (I'd still rather finish the current 
issues and then decide) and recharter to include the split document, I've no 
objection to that.  My objection is the idea (which was one of several being 
thrown around) to drop Section 9 without rechartering and then make 4408bis 
dependent on a draft no one is chartered to right.

My point in this particular case is that "non-normative, doesn't actually 
specify anything" does not inherently equate to "can be removed".

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Wed, 05 Sep 2012 14:09:26 -0700

Hi Scott,

It looks like there are a lot of issues for Section 9.  Are you 
planning to do a major rework of the section, or should we open 
issues for all of them?

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 5 Sep 2012 14:12:00 -0700

> specify anything" does not inherently equate to "can be removed".

I wasn't applying that statement to all sections.  Obviously a
protocol document needs non-normative stuff to enable people to make
sense of it, and Security Considerations and other required sections
are critical.

I think this is a continuation of the discussion about what's core and
what isn't.  For example, if we agree that SMTP is primarily a
signaling mechanism between the apparent sending ADMD and a receiver,
then the protocol is effectively done once check_spf() is able to
return a result.  Anything that happens after that is technically not
part of SPF, and that's the kind of stuff that could be trimmed from a
core document.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 05 Sep 2012 17:15:09 -0400

> part of SPF, and that's the kind of stuff that could be trimmed from a

Perhaps.  I agree it's likely we'll want to split, but I'd prefer we deal with 
the question of how to arrange the collected work until after we finish working 
through the issues and see what we have to deal with.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 05 Sep 2012 17:16:43 -0400

> planning to do a major rework of the section, or should we open

I think opening issues is useful.  I've taken a first pass at it, but no doubt 
it needs more work.  In terms of what I'm planning, I'm still planning on 
waiting to hear back from you/Andrew on the reorganization you directed before 
I do more on the document.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Wed, 05 Sep 2012 14:30:15 -0700

> through the issues and see what we have to deal with.

That's probably ok.  If we are lucky, it's only the difference between 
form and substance.  The form matters, but not as much as the substance.

The one issue that could change this is when the form creates confusion. 
  It's possible that some set of issues become much easier to deal with, 
if we separate things out.

This is merely a classic divide and conquer approach, but done right it 
often creates much better discipline and clarity in thinking about a 
topic.  However I'm not expressing a preference for this, yet.

d/

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: S Moonesamy <[email-masked]>
Date: Thu, 06 Sep 2012 09:14:37 -0700

Hi Scott,
>I do more on the document.

Given the way the discussion developed, we came to a different 
conclusion about Section 9, so we're not sure about moving it now.

Could you please suggest a plan on how to rework Section 9?  It would 
help Andrew and me, and the WG, to have a better view of the work?

Thanks
S. Moonesamy
SPFBIS WG co-chair

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 06 Sep 2012 17:19:19 -0400

> help Andrew and me, and the WG, to have a better view of the work?

Certainly.  Tomorrow I'll try to put something together and wrap up the 
pending changes I have into a -07 draft for people.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 07 Sep 2012 16:18:37 -0400

> help Andrew and me, and the WG, to have a better view of the work?

I see three possible fates for Section 9:

1.  Keep it in 4408bis.  This is the most direct logical extension of RFC 4408 
and in keeping with what I view as the spirit of our charter (minimal diff to 
get out of experimental and onto the standards track).  It is certainly 
consistent with the charter.  It does however bring a fair amount of "How to" 
type of text into a standards track RFC that is better suited to a BCP.  This 
may make IETF last call and IESG approval harder and risks getting directed to 
rework it later.

2.  Remove all of Section 9 and move it to a new document.  As it stands, this 
would require a normative reference from 4408bis to the new document.  This 
new document would be outside our WG charter.  I do not think it would be 
appropriate to make our chartered deliverable dependent of work no one is 
chartered to do, so I believe this would require rechartering to add the new 
deliverable.  This would result in two documents that supersede RFC 4408 which 
I think complicates things for document readers, but may be easier to get 
approved (I still find the DKIM documents confusing and between the original 
splits and the updates find myself looking through several of them to find the 
correct version of what I'm looking for).

3.  Split out some/most of Section 9 into a new document, but leave enough 
information in 44408bis (either in Section 9 or in other parts of the 
document) that the reference to the new draft for the split can reasonably be 
informational.  In this case, we should still recharter, but it retains enough 
information in one document (4408bis) for most implementers to develop code to 
support the protocol.  The split draft then is mostly deployment advice that's 
for a different audience and clearly BCP material.

Regardless of which choice the WG coalesces around, the choices are about 
arrangement of the text, not particularly about the text itself.  As has been 
mentioned, I took an initial pass at recasting some of the text in modern 
email arch terms, but it needs more work (and there's at least one issue open 
about this).  I would prefer to work on getting the text ~right independent of 
where the text lives, so while we can discuss where it ends up, let's continue 
to focus on content for now.  Once the content is ~done, where it goes will be 
easy enough to figure out I suspect.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Fri, 07 Sep 2012 15:00:23 -0700

Hi Scott,

I'll comment as an individual to explore the alternatives.  I haven't 
discussed the matter with Andrew yet.  Some of the decisions would be 
up to the Area Director.

>and in keeping with what I view as the spirit of our charter (minimal diff to

[snip]

>may make IETF last call and IESG approval harder and risks getting 

Yes.

>would require a normative reference from 4408bis to the new document.  This

There is a mention in Section 9 of RFC 4408 that the section is 
non-normative.  Why would there have to be a normative reference?

>deliverable.  This would result in two documents that supersede RFC 

Rechartering would be up to the Area Director.  By the way, there can 
only be one document that obsoletes RFC 4408.

>correct version of what I'm looking for).

Ok.

>for a different audience and clearly BCP material.

If I understood correctly, the question is about what deployment 
advice to have (which parts to keep) in 
draft-ietf-spfbis-4408bis.  Could you please suggest which parts are 
important for implementers to develop code to support the protocol?

>easy enough to figure out I suspect.

Thanks for explaining this.

Regards,
S. Moonesamy (speaking for myself)

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 7 Sep 2012 15:43:48 -0700

On Fri, Sep 7, 2012 at 3:00 PM, S Moonesamy <[email-masked]> wrote:
> Rechartering would be up to the Area Director.  By the way, there can only
> be one document that obsoletes RFC 4408.

I don't think this requires a rechartering, but only a change in
milestones, since ultimately the aggregate output is the same.  But
really that's between the AD and the co-chairs.

> Thanks for explaining this.

+1.

I'm hoping to do a higher-level pass over -07 very soon, more focused
on the arrangement of the material and IETF procedural questions
rather than techincal stuff.  I'll do that ASAP.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 07 Sep 2012 18:48:48 -0400

> non-normative.  Why would there have to be a normative reference?

As we've recently discussed, just because text is non-normative, that does not 
equate to it being removable in the spec.  The example that most immediately 
comes to mind is that in the definition of fail, we say receiver actions based 
on fail are a matter of local policy.  The only place we currently define what 
we mean by local policy is in section 9.  While there is no normative guidance 
in Section 9 that affect RFC 2119 type implementation decisions, I don't think 
it's possible for implementers to properly execute SPF without some 
understanding of at least some of the text in Section 9.

> >chartered to do, so I believe this would require rechartering to add the
> >new deliverable.  This would result in two documents that supersede RFC
> >4408 which
> 

OK.  Since if we do split, 4408bis would reference the new document in some 
manner, I think that's not an issue.

> >approved (I still find the DKIM documents confusing and between the
> >original splits and the updates find myself looking through several of
> >them to find the
> >document) that the reference to the new draft for the split can reasonably
> >be informational.  In this case, we should still recharter, but it
> >retains enough

See above for one example.  I haven't done a complete analysis.  I think it 
can wait until we're doing working through the issues.

> >arrangement of the text, not particularly about the text itself.  As has
> >been mentioned, I took an initial pass at recasting some of the text in
> >modern email arch terms, but it needs more work (and there's at least one
> >issue open about this).  I would prefer to work on getting the text ~right
> >independent of

You're welcome.

Scott K

---

From: Barry Leiba <[email-masked]>
Date: Sun, 9 Sep 2012 10:19:43 -0400

Comment only on the charter issue here, from the irresponsible AD; the
chairs should discuss this with the responsible AD, regardless of
where the WG ultimately decides to go with it, to get a sense of how
he sees the charter in this regard.

> deliverable.  This would result in two documents that supersede RFC 4408

The charter says this:

It does not say that changes to the *document* will be so limited, but
that changes to the *specification* will be.  I believe that it's a
question of working-group management to decide whether a specification
lies entirely in one document or is split among two or more.  I do
*not* think a rechartering is needed if the working group decides that
the best way to publish the specification is in two documents, as long
as the intent of the above charter text is met.  I think such a split
*can be* within the current charter if it's done right.

Partly for that reason and partly because of where the tendrils of the
specification lie, I *do* think that the documents would all have to
normatively reference each other.

And, of course, the milestones would need to be changed, which the
chairs can do in consultation with the responsible AD.

*If* this path is chosen, I would say that it should be the main
protocol specification document that officially does the "Obsoletes
4408".  But, yes, the SPF specification would now be in a set of
documents, and Scott is right that that can cause some amount of
confusion.  But a number of important specs have done that: MIME,
notably, many years ago; HTTP more recently, splitting RFC 2616 into
seven parts for the "bis" work.

I'm not addressing whether or not it's a good idea to do such a split
here, but only what my opinion of the split is as a process matter.

Barry, kibitzing AD

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 9 Sep 2012 09:56:50 -0700

> here, but only what my opinion of the split is as a process matter.

All of that is my understanding as well.

My vision of a split (which still rises only to the level of
"something worth considering") involves putting all the
protocol-specific stuff in one document, which is itself 4408bis, and
then all the deployment guidance in another.  In essence, all of the
normative stuff is in one document along with only critical
informative stuff, and everything else goes in the other.

I'm not sure about the mandatory normative references stuff; I suggest
the informational doesn't need to be a normative reference of the
proposed standard merely because the charter said they have to be
produced together, but I do agree they need to come out pretty much
simultaneously.

Barry listed a few examples of specifications that are multi-document.
 A couple of others include the DNS core (1034 and 1035) and more
recently DKIM (core, threats document, deployment advice, overview,
ADSP, and use of DKIM with mailing lists).

I have it on my to-do list to produce, hopefully this weekend, an
outline-level overview of what I have in mind for the WG to consider,
and I'm happy to help do the work of the split rather than saddling
Scott with all of it.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Sun, 09 Sep 2012 10:16:48 -0700

> and I'm happy to help do the work of the split rather than saddling

me too.

d/

---

From: Dave Crocker <[email-masked]>
Date: Sun, 09 Sep 2012 10:20:26 -0700

> normatively reference each other.

That depends entirely on the nature of the document divisions that are done.

My usual view is that documents that need to normatively refer to each 
other have probably done a poor split.  Some more hierarchical, with 
normative pointers in one direction, should be greatly preferred.

An example of the reason for this is that mutual normative reference is 
likely to cause problems when one of the documents is revised.

d/

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 10 Sep 2012 11:14:01 +0200

> normative pointers in one direction, should be greatly preferred.

+1, that's how RFC 2026 seems to suggest an AS (split Section 9)
should refer to a TS (polished 4408bis).