The IAB chair, IETF chair, and the IAB liaison coordinators should have no restrictions on populating LS To and From fields.

[rjsparks]

Reasoning: These roles may want to file LSs on behalf of others, or may need to populate the From field with multiple entries

• In summary, these restrictions are proposed:
  • Secretariat, IETF chair, IAB chair, IAB liaison coordinators: No restrictions
  • AD: AD area group or any working group that the AD is responsible for can be put in the From field (maybe also IESG/IETF as From?)
  • WG chair: Only their WG is allowed in From field
  • Liaison manager: Only their liaison organization can be put in To field
• People with multiple roles (e.g. WG chairs and liaison managers) will have the union of their permissions.

[rjsparks]

Sending messages with multiple From entries, while supported by the standards, is very poorly supported by deployed systems. Many silos treat such messages as spam. There are also issues with underlying libraries that use the From for signing and verifying bits of the messages.

Or is this intended only to apply to the content of the liaison statement instead of the email headers?

[mirjak]

The actually sender email address is anyway statements@ietf.org. This is more how to populate the fields. Actually looking at what other SDOs do, the "From" and "To" fields are basically "just" group names (without having an email address directly associated with it) and all sender email addresses should go into the "Response contact" and all receiver email addresses should go into the "cc" field.

So e.g. if I select a certain working group as from, the chairs (I would say individual) email addresses and the wg list, should be added to the "response contact" field. However, I think we should still make it possible to edits these entries manually. E.g. removing the list address if that is appropriate.

Also for outgoing liaison statement, I think both the liaison manager (if applicable) and the liaison-coordination@iab.org address should be part of the "response contact" (instead of "cc") as that would make it more clear that those should be added to any kind of reply. But as noted in issue #10 as well, we probably want to not make those editable/removable.

Note that both the addresses in the "cc" field and the "response contact" field will end up in the cc of the actually email send out. This is also related to ietf-tools/datatracker#5221 in the datatracker GitHub.

And as we are talking about these field. We also have an issue for RFC4053bis to remove the "technical contact" as this is really rather unclear and not much used. See intarchboard/draft-iab-rfc4053bis#3

The only other thing we could consider to record better is who has enter the LS into the datatracker. You can look that up in the history but this is not very easily visible. Also it would be important to rather note the role in which the person acted when entering the LS. That mean one would not only need to link this to a datatracker account but also let the issuer select a role (e.g. IAB chair or wg chair of liaison manager) as some people have multiple roles they could use to enter a statement. Also when the secretariat enters a LS it only shows the name and email address in the history but many people don't know that a certain person is part of the secretariat. So making that more clear would also be important. However, maybe this should be a separate issue as it might be harder to connect specific roles accordingly...?

[jennifer-richards]

@mirjak (and anyone interested), I've done some refactoring and adjusting of the options available to various roles. Please have a look at the summary in the description here: ietf-tools/datatracker#8883 and confirm whether those look appropriate. I believe I've called out the actual changes with bold comments in the list, but it would be good to review all of it.

The "IAB Executive Director" in particular does not seem to exist in the datatracker. I've treated that as equivalent to the IAB chair as far as permissions but I don't know whether that's needed or appropriate so would appreciate feedback.

(I've also not yet added modeling of the Liaison Coordinator roles, so those are not described over in the pull request)

Thanks!

[JayDaley]

@jennifer-richards The "IAB Executive Director" role is an admin role, similar to the IESG Secretary role in the IESG.

[jennifer-richards]

@jennifer-richards The "IAB Executive Director" role is an admin role, similar to the IESG Secretary role in the IESG.

👍

The datatracker does not have such a role assigned at the moment, at least, not modeled as a role named Executive Director for the IAB group.

[mirjak]

As discussed in discussion #7 execd@iab.org is currently cc on all LSs. This is the email alias for the IAB Executive Director which is a admin role hold by the secretariat, as Jay said. As discussed in #7 we actually don't want to have this address cc'ed in future and as such I don't think it is necessary to create a separate role from just the secretariat role that we usually use in the datatracker.

Actually this would only be useful if the secretariat says they would prefer to have different roles with different rights rather than giving all people from the secretariat full access. However, that seems a complete separate question.

[rjsparks]

Moved this:

The only other thing we could consider to record better is who has enter the LS into the datatracker. You can look that up in the history but this is not very easily visible. Also it would be important to rather note the role in which the person acted when entering the LS. That mean one would not only need to link this to a datatracker account but also let the issuer select a role (e.g. IAB chair or wg chair of liaison manager) as some people have multiple roles they could use to enter a statement. Also when the secretariat enters a LS it only shows the name and email address in the history but many people don't know that a certain person is part of the secretariat. So making that more clear would also be important. However, maybe this should be a separate issue as it might be harder to connect specific roles accordingly...?

to #37