Minutes interim-2024-emailcore-01: Tue 16:00
minutes-interim-2024-emailcore-01-202412031600-01

EMAILCORE

EMAILCORE December 2024 Interim meeting (online)

Tuesday 3 December 2024
16:00 (UTC) 90 minutes

Chairs: Alexey Melnikov, Todd Herr

Issue 102 (Functional Groups)

• Text in rev -36 is intended to clear up definition.
• Working group to review and raise objections on list.

Issue 108 (Further deprecate TURN?)

• Rev -36 contains sentence highlighting ETRN as a substitute for
  deprecated TURN
• Working group to review and raise objections on list.

Issue 116 (Mention "or HELO" each time "EHLO" is mentioned)

• Lists of applicable occurrences in SMTPbis have been created and
  mentioned on slide

• Alternative proposal is to do two smaller updates, which have been
  put in rev -36

  • Resnick - Differences in lists due to human error, so leave them
    alone

  • Crocker (in chat) - Other alternative is to introduce a
    construct like "xHLO" and declare it to map to both

    • Melnikov and Resnick express lack of support for this idea

  • Klensin (in chat) - Let's not do anything that makes things
    worse

• Working group to review text in rev -36 and raise objections on list

Issue 123 (Should we deprecate HELO?)

• Initial reaction from chair is "No, but let's talk"
• Klensin - Preference to not do this, but felt that the question
  should be asked
• Resnick (in chat) - Leave it alone
• Leiba - Leave it alone, maybe mention in A/S
• Klensin - A/S can mention that using HELO is antiquated at best

Issue 125 (Rearrange Section 4.1.1.4)

• Issue asserts that fourth paragraph is confusing
• Suggestion was to basically swap fifth and sixth paragraphs

• Klensin - No objection to doing this if it makes it better, worried
  about unintended consequences.

  • Wants working group consensus on this before moving forward

• Resnick - Doesn't believe swapping paragraphs is a problem

• Kucherawy (in chat, as participant) - LGTM
• Melnikov - Let's make the change

Issue 114 and Issue 122 (Sections 6.1 and 6.2)

• Slide shows orignal text vs. Gondwana/Herr proposed text vs. Crocker
  proposed text
• Melnikov expresses preference for Crocker's version
• Leiba prefers keeping the MUST, but happy to go with consensus on
  Crocker's version
• Kucherawy (as individual) - Agree with Barry
• Klensin (in chat) - Barry +1 but very slightly
• Kucheraw (in chat as individual) - In Crocker's proposal: change
  "piece of mail" to "message" to be consistent with rest of paragraph
• Melnikov - Move forward with Gondwana/Herr proposed text
• Klensin - Gondwana/Herr version already in current version of
  SMTPbis

Issue 124 ("other contemporary standards")

• Two versions of proposed text from Klensin shown on slides
• Herr questions use of "repertoire" in version 2; Klensin educates
  him that it is the correct term
• Melnikov expresses preference for version 2
• Kucherawy expresses preference for version 2
• Resnick (in chat) - Possible typo "complete or for", might should be
  "completely, or for"
• Make it read "restrictions completely, or specifically, to the
  current body content"
• Version two is the winner, with edit shown in previous bullet

Issues 109 (STARTTLS discussion) and 113 (Advantages of transport and
encryption)

• Klensin is okay with Kucherawy's proposed text
• Kucherawy (in chat) - I'd be fine with being explicit about STARTTLS
  and maybe AUTH, and kicking DKIM and SPF to the AS.
• Resnick (in chat) +1 to Murray
• Klensin proposes modification to Kucherawy's proposed text,
  specifically dropping bits in bold on slide
• Crocker - Agrees with everything Murray said. Dropping bolded text
  seems like an improvement.
• Resnick - Fine with dropping bolded text in principle, but
  impression was that this was about satisfying concerns of secdir and
  Security ADs. Worried about not mentioning STARTTLS in particular
• Kucherawy - Prefers dropping it with breadcrumb pointing to STARTTLS
  discussion in A/S

• Crocker - Forward references to other documents creates a
  dependency; reference documents should be pointed to by
  corresponding A/S, not the other way around.

  • Acknowledge the issue, but don't try to solve it here. Note that
    issue is out of scope for SMTPbis

• Leiba - Agree with Dave. Wouldn't object to informative reference to
  STARTTLS

• Kucherawy (in chat) - Shipping a protocol document from ART that has
  no transport security capability will draw ire from UTA WG too.
• Melnikov - For practical reasons will need to ship SMTPbis and A/S
  together
• Leiba - Would really not like to tie SMTPbis to A/S
• Melnikov - Reluctant to send SMTPbis for IESG review without knowing
  when A/S will be done
• Leiba - Alternative is to put in shepherd writeup that current draft
  of A/S should be read alongside SMTPbis
• Melnikov - Happy to try that. Worth noting that A/S already exists,
  as opposed to telling IESG that EMAILCORE "will write a new document
  in the future".
• Klensin - Informative reference to A/S already exists in SMTPbis.
  Likes Leiba's suggestion re:shepherd writeup.
• Murchison (in chat) - our charter says the following about the A/S:
  "5321bis and 5322bis will be submitted for publication before this
  document is finalized"
• Resnick - Putting a mandatory MUST use STARTTLS in SMTPbis is a hill
  we want to die on, i.e., We do not want that in SMTPbis
• Kucherawy (in chat) - I'm fine with defending our preferred text to
  the IESG. I also suggest we should think about a backup plan we can
  live with in case that doesn't work.

Issues 109 and 113 cont'd

• Section 7.1
• Kucherawy (in chat) - I think this is another case where we can talk
  about end-to-end security being a common concern for which solutions
  exist, go do your homework.
• Leiba - Rather say less than more; leave detail to A/S
• Klensin - Agree with Leiba. Charter says we're not to talk about
  message submission, going there doesn't make any sense.
• Kucherawy (in chat) - +1 to "punt to A/S"

Next steps

• Klensin to release rev -37, prefers another WG Last Call

• Interim for early 2025?

  • Klensin thinks this interim should be strictly about A/S
  • Kucherawy asked about A/S-focused interim possibly later in
    December
  • Melnikov - Mid to late January

• Resnick (in chat) - We may need the interim to deal with IESG
  pushback on 5321bis.

• Leiba (in chat) - Getting a January interim on our calendars now...
  might be best.
• Kucherawy - Do we want documents to go as a cluster to avoid forward
  reference to drafts?
• Kucherawy (in chat) - Two interims might be necessary (one A/S, one
  for rfc5321bis). Both in January is fine. I would love to get all
  three of these done (in the RFC Editor queue) before I step down,
  but that's certainly not a hard requirement.
• A/S Interim week of January 13, SMTPbis interim subsequent to that
  after IESG review

Meeting concludes.

Chat transcript follows:

ietf-121
Alexey Melnikov
10:55
Hi all. I will do a sound check in 5 mins or so. Be right back.
Dave Crocker
10:56
Does anyone else have the session being displayed rotated 90 degress to
the left?
Alexey Melnikov
10:57
Not on my laptop, no.
John Klensin
10:59
Nope. Looks fine here
Pete Resnick
11:01
More important to check for us unusual suspects.
Alexey Melnikov
11:01
I can't possibly know what I don't know ;-)
Murray Kucherawy
11:06
My first ever interim. No wise cracks, please.
Pete Resnick
11:07
https://author-tools.ietf.org/iddiff?url2=draft-ietf-emailcore-rfc5321bis-36
makes life easy
Pete Resnick
11:11
The differences between our lists were due to human error AFAICT, not
because there was something obscure going on. That points to leaving
them alone.
Dave Crocker
11:11
an alternative is to introduce a construct like xHLO and declare it to
map to both.
Pete Resnick
11:12
@Dave: I think that leads to the same problem: We might screw up where
we introduce that.
Dave Crocker
11:13
sunglasses
John Klensin
11:13
My goal, going back to the first interaction with Donald, was that we
not do anything that makes things worse -- by human error or otherwise.

Murray Kucherawy
11:13
Is it time to inject "It's worse than you think?"
Murray Kucherawy
11:14
Agree with "riskier", not worth it.
Pete Resnick
11:15
Meh. Leave it alone.
Murray Kucherawy
11:19
+1 LGTM
(as a participant)
Murray Kucherawy
11:21
I slightly prefer Dave's, though change "piece of mail" to "message" to
be consistent with the rest of the paragraph.
John Klensin
11:26
Barry +1 but very slightly)
Pete Resnick
11:26
I vaguely remember the discussion from 1999 that introduced that
sentence, but cannot find anything in the DRUMS archive about when it
happened.
Murray Kucherawy
11:27
How many versions of the DRUMS draft were there?
Probably a pain to check all of them.
The datatracker might do well with a "blame".
Murray Kucherawy
11:28
Yep.
John Klensin
11:28
Murray: a bunch. And my notes about specific controversies in putting
what became 2821 together do not identify any arguments about it.
Murray Kucherawy
11:35
I think I prefer (2) because (1) and the original have a dangling "if".
What if the content does not conform to ...? What alternatives are
there?
Pete Resnick
11:36
"complete or for" in the last line seems like a typo.
completely or for
I think strike the "or"
Murray Kucherawy
11:37
I think it's right as is, or maybe add a comma after "completely"
Pete Resnick
11:38
"Whatevah", as my NY friends would say.
Murray Kucherawy
11:39
Missing commas can be very important.
Pete finds inspiration in cooking his family and his dog.
Pete Resnick
11:39
"completely or, specifically, for..."
Pete Resnick
11:40
Yes, that works for my soft brain which misread it the first time.
Murray Kucherawy
11:42
I'd be fine with being explicit about STARTTLS and maybe AUTH, and
kicking DKIM and SPF to the AS.
Pete Resnick
11:43
@Murray: +1
Todd Herr
11:44
starting to???
Murray Kucherawy
11:47
The "Extensions ..." sentence is incomplete. Did I write that? ugh.
There's an "are" missing, I think.
John Klensin
11:47
Replace bolded text with an explicit "There is additional discussion of
this in the applicability statement" or something like that?
John Klensin
11:49
I agree with Dave.
Murray Kucherawy
11:49
That's a good point. Then I suggest we try without, but be willing to
add STARTTLS if cornered.
Murray Kucherawy
11:51
Shipping a protocol document from ART that has no transport security
capability will draw ire from UTA too. :)
Murray Kucherawy
11:52
Can we get away with making allusions to "a future applicability
statement" without making it a normative reference?
Pete Resnick
11:52
@Murray: As John said, already mentioned.
Barry Leiba
11:52
I think it doesn't need to be normative.
Murray Kucherawy
11:52
Works for me.
Barry Leiba
11:53
Happy to go in the direction JCK just said.
Murray Kucherawy
11:53
+1
Murray Kucherawy
11:54
Who did John say is pushing DKIM? Karl?
Barry Leiba
11:54
Nooooooooooo
Kenneth Murchison
11:57
our charter says the following about the A/S: "5321bis and 5322bis will
be submitted for

publication before this document is finalized"
Murray Kucherawy
11:58
I'm fine with defending our preferred text to the IESG.
I also suggest we should think about a backup plan we can live with in
case that doesn't work.
Todd Herr
11:59
@pete - Did you say "MUST use STARTTLS is a a hill we want to die on"?
Pete Resnick
11:59
@Todd: Yes, we do not want to add that to the document.
Murray Kucherawy
12:00
I think this is another case where we can talk about end-to-end security
being a common concern for which solutions exist, go do your homework.
Murray Kucherawy
12:02
+1 to "punt to AS"
Murray Kucherawy
12:06
+1 to this plan
Pete Resnick
12:06
+1 to John's suggestion for 5321bis and interim only for the a/s.
Murray Kucherawy
12:06
Could we even do the AS-focused interim later in December?
Pete Resnick
12:09
We may need the interim to deal with IESG pushback on 5321bis.
Barry Leiba
12:11
Getting a January interim on our calendars now... might be best.
Pete Resnick
12:11
@Alexey: Fair. An a/s interim sounds good.
Pete Resnick
12:12
+1 for cluster
Murray Kucherawy
12:12
Two interims might be necessary (one AS, one bis).
Both in January is fine.
Pete Resnick
12:12
ack
Murray Kucherawy
12:12
I would love to get all three of these done (in the RFC Editor queue)
before I step down, but that's certainly not a hard requirement.
Pete Resnick
12:15
I love happy thoughts!
Murray Kucherawy
12:15
I'll have what he's having.
Pete Resnick
12:16
@Murray: Now that's a good reference!