Subject: [ietf-smtp] An Applicability Stateement for core email specifications - and request for AD advice/instructions

From: John C Klensin <[email-masked]>
Date: Sun, 08 Mar 2020 13:49:29 -0400

(personal opinion, not wearing any particular hat)

Hi.

Discussions on this (ietf-smtp) list since before IETF 106 and
the informal proposals to try to revise RFCs 5321 and 5322 and
get them done before now (!), have convinced me, and I think at
least some others, that an Applicability Statement or BCP --one
that can cover current advice for application and use of
provisions of the core protocols and related ones -- is going to
be key to an actual revision effort for 5322 and (especially)
5321 being a matter of weeks or a few months rather than years
of work.

If we are going to continue discussions in anticipation of an
eventual WG, I think it would be helpful to get an outline of
what might be in, or evolved into, such an A/S or BCP posted
soon.  It could act, not only as a placeholder but a place to
keep (historically archival, because that might be important)
notes of what we expect to put there, partially so that we could
put pointers and references into 5321bis/5322bis.

Its presence as a placeholder could also help with constructing
a draft WG Charter.

I guess I am, reluctantly, willing to sign up to produce a first
cut at such an (-D or an outline of one (although certainly not
before tomorrow's posting deadline). But my condition for doing
so would be a volunteer for co-author who would be willing to
take over the work and maintain the document.  That would be a
good opportunity for someone new at this work, possibly more
involved in day-to-day operations of large email systems, and
with a different perspective on things than I have.  So, unless
others object or the ADs have conflicting advice, volunteers
sought.

On a similar note, I have been maintaining a list of possible
issues and changes to 5321 in Appendix G of 5321bis.  I'm
willing to continue to do that, but it may be that either a
formal tracker or an IETF-sanctioned Github repository would be
a better way to manage and facilitate discussion on those topics
and where they belong.  Other than a personal distaste for
trying to track long and complex discussions that I cannot read
in real time in Github, I have no preference among the three
options.  But I don't think setting something up requires a WG
or even a firm plan/ draft charter for one and so, if others
(particularly the ADs or or potential WG chairs) have strong
opinions, this would be, IMO, a good time to get them posted.

best.
   john

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 16 Mar 2020 11:40:29 +0000

Hi John,
I am finally catching up with a few outstanding requests.

> On 8 Mar 2020, at 17:49, John C Klensin <[email-masked]> wrote:
> 

I personally like this idea. So +1 from me.
> before tomorrow's posting deadline).

Please do!

> But my condition for doing

I am willing to help out with this one, if you like someone not junior (in addition to a more junior person).
> opinions, this would be, IMO, a good time to get them posted.

While I don’t particularly like GitHub interface (I love git itself), I think it is the more commonly used tool these days. (My next choice would be trac on tools.ietf.org)

I can set one up, if there is rough agreement to use GitHub.

Best Regards,
Alexey

---

From: John C Klensin <[email-masked]>
Date: Tue, 17 Mar 2020 19:45:50 -0400

Alexey,

Thanks for getting to this in the middle of all of the other
chaos.

Inline below.

--On Monday, March 16, 2020 11:40 +0000 Alexey Melnikov
<[email-masked]> wrote:

>> get them done before now (!), have convinced me, and I think
>> at least some others, that an Applicability Statement or BCP
>> --one that can cover current advice for application and use of
>> provisions of the core protocols and related ones -- is going
>> to be key to an actual revision effort for 5322 and
>> (especially) 5321 being a matter of weeks or a few months
>> rather than years of work.
>> 
>> notes of what we expect to put there, partially so that we
>> could put pointers and references into 5321bis/5322bis.
> 
>> Its presence as a placeholder could also help with
>> constructing a draft WG Charter.
>> 
>> I guess I am, reluctantly, willing to sign up to produce a
>> first cut at such an (-D or an outline of one (although
>> certainly not before tomorrow's posting deadline).
> 
> Please do!

Unfortunately, while I had a clear picture of how to put that
together when I wrote that note, the passage of time and general
disruptions cleared it from memory.   Will try to reconstruct
within the next several days, depending in part on how you
(collectively and Barry in particular would like me to
prioritize it relative to RFC-to-be 8753.
 
>> with a different perspective on things than I have.  So,
>> unless others object or the ADs have conflicting advice,
>> volunteers sought.
 
> I am willing to help out with this one, if you like someone
> not junior (in addition to a more junior person).

Especially since you presumably acquire free time next week,
that would be great.  As this moves forward, you (or Barry and
Murray) also need to find a WG Chair or co-chairs and being one
of the latter would also be a good learning opportunity for
someone who hadn't done it before (IMO, it would be wonderful if
you felt like taking the more senior role on because you have
the both the IETF expertise and the long-term email
perspective).   For this A/S document, I just don't want people
to depend on me longer-term as sole editor because I suspect I
will have my hands full with 5321bis.

>> formal tracker or an IETF-sanctioned Github repository would
>> be a better way to manage and facilitate discussion on those
>> topics and where they belong.  Other than a personal distaste
>> for trying to track long and complex discussions that I
>> cannot read in real time in Github, I have no preference
>> among the three options.  But I don't think setting something
>> up requires a WG or even a firm plan/ draft charter for one
>> and so, if others (particularly the ADs or or potential WG
>> chairs) have strong opinions, this would be, IMO, a good time
>> to get them posted.
> 
> While I don't particularly like GitHub interface (I love git
> itself), I think it is the more commonly used tool these days.
> (My next choice would be trac on tools.ietf.org)
> 

I'm happy to leave this decision to others.  It is partially the
interface, or maybe a sign of advancing age, but I have found
GitHub almost impossible to follow and track for long,
multi-thread discussion.  In that respect, the advantage of trac
is precisely that it can keep an issues list but encourages the
action discussions to take place on a mailing list, while
GitHub, in practice, seems to discourage that.

Hope everyone is well and staying that way.

best regards,
   john