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

[John C Klensin <[e-mail]>]

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
<[e-mail]> wrote:

> Hi John,
> I am finally catching up with a few outstanding requests.
> 
>> On 8 Mar 2020, at 17:49, John C Klensin <[e-mail]>
>> wrote:
>> 
>> (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.
> 
> I personally like this idea. So +1 from me.
>> 
>> 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.
 
>> 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.
 
> 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.

>> 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.
> 
> 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.

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