Subject: [marf] Reported-Domain vs Reported-URI

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 3 Feb 2010 10:48:59 -0500

Question:

The current draft has both Reported-Domain and Reported-URI included.
As per RFC 4501, there is a URI syntax used for domain names. For
example:

dns:www.example.org

Even specific DNS records can be pointed to like:

dns://192.168.1.1/ftp.example.org?type=A

Do we need both fields?

Yakov

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 3 Feb 2010 09:42:22 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Yakov Shafranovich
> Sent: Wednesday, February 03, 2010 7:49 AM
> To: [email-masked]
> Subject: [marf] Reported-Domain vs Reported-URI
> 
> Question:
> 

[as participant]

If we take the perspective that the base draft primarily documents existing practice, then we should include both only so that compatibility with existing implementations is maintained.

But strictly from a standards perspective, I believe it is indeed redundant.

We could note the redundancy explicitly, and explain why it was included anyway.

But one interesting point is that RFC4501 isn't referenced by the base draft.  Should we add such a reference, or is simply referring to the base URI RFC sufficient?

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 3 Feb 2010 12:52:56 -0500

> But one interesting point is that RFC4501 isn't referenced by the base draft.  Should we add such a reference, or is simply referring to the base URI RFC sufficient?

I didn't reference any of the URI RFCs, the assumption is that people
will use the URI registry. Perhaps we should add a blurb referencing
the registry like this:

"Implementors should be aware that the Reported-URI field can carry
many different types of data depending on the URI scheme used. For
more information, please consult the URI registry maintained by IANA
[http://www.iana.org/assignments/uri-schemes.html].

Furthermore, it is outside the scope of this standard whether the data
carried in this field implies any additional information. Implementors
may negotiate their own agreements surrounding the interpretation of
this data"

Yakov

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 3 Feb 2010 09:55:19 -0800

> From: Yakov Shafranovich [mailto:[email-masked]]
> Sent: Wednesday, February 03, 2010 9:53 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: Re: [marf] Reported-Domain vs Reported-URI
> 

I think pre-WG, when I added the ABNF I added a reference to the basic URI RFC, namely RFC3986.  It appears as a normative reference in the current draft.

> may negotiate their own agreements surrounding the interpretation of

Any +/- 1s for this text?

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 3 Feb 2010 13:29:59 -0700

> Any +/- 1s for this text?

+1

--
J.D. Falk <[email-masked]>
Return Path Inc

---

From: Barry Leiba <[email-masked]>
Date: Thu, 4 Feb 2010 12:41:27 -0500

> Any +/- 1s for this text?

+1, as participant.

Also, as chair, I'll point this out:
> If we take the perspective that the base draft primarily documents
> existing practice, then we should include both only so that compatibility
> with existing implementations is maintained.
>

The spec can certainly document existing practice while deprecating
it.  That would involve text that explains the redundancy, says that
one of the items is now deprecated, and says that implementations
SHOULD NOT generate the deprecated item.

Barry

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 4 Feb 2010 12:43:41 -0500

> SHOULD NOT generate the deprecated item.

Do we have any proposed text for this?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 4 Feb 2010 10:01:30 -0800

> Sent: Thursday, February 04, 2010 9:44 AM
> To: [email-masked]
> Cc: [email-masked]

...and is there consensus that we should deprecate Reported-Domain?

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 05 Feb 2010 11:55:03 +0100

> may negotiate their own agreements surrounding the interpretation of

While I like the first paragraph, the 2nd one adds to the concept that 
the semantics of ARF data may vary widely. Shouldn't we try to promote 
an unambiguous meaning of each field?

My understanding, based on previous discussions, is that 
Reported-Domain is the mail domain responsible for sending the 
purported spam, while Reported-URI is a spamvertized mailbox (e.g. 
Reply-To) or web page whose monitoring is being requested. If that's 
correct, I'd see no reason for eliminating any of them.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 05 Feb 2010 08:24:49 -0800

+1

---

From: Yakov Shafranovich <[email-masked]>
Date: Fri, 5 Feb 2010 11:30:32 -0500

On Fri, Feb 5, 2010 at 5:55 AM, Alessandro Vesely <[email-masked]> wrote:
> While I like the first paragraph, the 2nd one adds to the concept that the
> semantics of ARF data may vary widely. Shouldn't we try to promote an
> unambiguous meaning of each field?
>
> My understanding, based on previous discussions, is that Reported-Domain is
> the mail domain responsible for sending the purported spam, while
> Reported-URI is a spamvertized mailbox (e.g. Reply-To) or web page whose
> monitoring is being requested. If that's correct, I'd see no reason for
> eliminating any of them.

Some senders and receivers interpret "Reported-Domain" as a domain
that was advertised within the message.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 8 Feb 2010 09:44:11 -0800

> Sent: Friday, February 05, 2010 8:31 AM
> To: Alessandro Vesely
> Cc: [email-masked]

This sort of ambiguous interpretation worries me.  It suggests we need some text that explains how the field should really be used by both ends of the feedback loop.

So let's find out what the most common use is and consider whether or not we should make that normative.

The spec currently says:

   o  "Reported-Domain" includes a domain name that the report generator
      believes to be relevant to the report, e.g. the domain whose
      apparent actions provoked the generation of the report.  Domain
      format is defined in section 2.3.1 of [DNS].

This is a bit vague.  If machine parsing is the intent, then the spec should indicate specifically how or why that domain might have been chosen.

So how are generators using this field?

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 09 Feb 2010 15:27:48 +0100

> This is a bit vague.  If machine parsing is the intent, then the spec should indicate specifically how or why that domain might have been chosen.

I'd say "responsible for injecting the original message", rather than 
"relevant to the report". The how and why would be expressed in the 
Authentication-Results feedback field (which may match its namesake in 
the original message's header.)

> So how are generators using this field?

I've seen "Reported-Domain: mail.tana.it" from AOL SComp. That name is 
not the helo name of the transmitter, but one of the PTRs associated 
with its address. They could have set "Reported-Domain: tana.it", 
based on SPF authentication, which might have been slightly more 
meaningful. Should the spec get down to detailing such sort of 
preferences?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 10 Feb 2010 10:41:18 -0800

> Alessandro Vesely
> Sent: Tuesday, February 09, 2010 6:28 AM
> To: [email-masked]
> > This is a bit vague.  If machine parsing is the intent, then the spec
> > should indicate specifically how or why that domain might have been
> > chosen.
> 

I think it should.  If an ARF recipient sees this but has no indication of the origin of the field's value, it has no assurances that it should or should not use that data in a particular way.

Let's say I get a few different ARFs from completely different FBL sources indicating "Reported-Domain: example.com".  Unbeknownst to you, one is reporting the HELO, one is reporting domain of a URL it found inside the message, one is the domain from the From: header field, one is the DKIM signature domain.  Is any correlation possible?  As a software developer, I would be tempted to discard that value as its meaning is undefined.

---

From: Steve Atkins <[email-masked]>
Date: Wed, 10 Feb 2010 10:59:03 -0800

On Feb 10, 2010, at 10:41 AM, Murray S. Kucherawy wrote:
> I think it should.  

I don't, really. If you get prescriptive to that level of detail then A) you make it less flexible and B) most everyone will ignore that section of the spec anyway. :)

> If an ARF recipient sees this but has no indication of the origin of the field's value, it has no assurances that it should or should not use that data in a particular way.
> 

That value is very useful for triage, even if I then need to do some work to work out why it's reported.

If I have 100 reports that all have "Reported-Domain: foo.example.co" then I know that there's some problem with foo.example.com, and I should escalate that incident with my staff, even before I've done any parsing of the individual messages.

If, on later parsing, 30 of them have it as a From: field, 20 as a URL, 30 as a HELO and 20 don't have any mention of it at all that doesn't really affect the value of the triage step.

Cheers,
  Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 10 Feb 2010 11:08:00 -0800

> Steve Atkins
> Sent: Wednesday, February 10, 2010 10:59 AM
> To: Message Abuse Report Format working group
> > If an ARF recipient sees this but has no indication of the origin of
> > the field's value, it has no assurances that it should or should not
> > use that data in a particular way.
> >
> > Let's say I get a few different ARFs from completely different FBL
> > sources indicating "Reported-Domain: example.com".  Unbeknownst to you,
> > one is reporting the HELO, one is reporting domain of a URL it found
> > inside the message, one is the domain from the From: header field, one
> > is the DKIM signature domain.  Is any correlation possible?  As a
> > software developer, I would be tempted to discard that value as its
> > meaning is undefined.
> 
> If I have 100 reports that all have "Reported-Domain: foo.example.co"
> then I know that there's some problem with foo.example.com, and I
> should escalate that incident with my staff, even before I've done any
> parsing of the individual messages.
> 
> If, on later parsing, 30 of them have it as a From: field, 20 as a URL,
> 30 as a HELO and 20 don't have any mention of it at all that doesn't
> really affect the value of the triage step.

But as has been mentioned here several times, the goal is automated parsing.  Does your statement still apply to someone trying to write code to handle ARFs in an automatic fashion when the real meaning of that field is unknown and could've been forged anyway?

If the answer (actually, the consensus) is "yes" then I'd like to see the document be explicit about why the source of that value isn't being specifically defined.  Would you care to suggest some text to that effect to be added?

---

From: Steve Atkins <[email-masked]>
Date: Wed, 10 Feb 2010 11:14:16 -0800

> But as has been mentioned here several times, the goal is automated parsing.  Does your statement still apply to someone trying to write code to handle ARFs in an automatic fashion when the real me…

Absolutely. The meaning of that field, to me anyway, is "This hostname is why we chose to send the report to you." with the implication that it's the thing you should key your triage handler on.

Anything in the original message could have been forged too, pretty much, and often is. FBL reports for spam where the spammer has cut and pasted content from mail you've sent, for use as filter-fodder isn't at all unusual.

> If the answer (actually, the consensus) is "yes" then I'd like to see the document be explicit about why the source of that value isn't being specifically defined.  Would you care to suggest some t…

"The hostname in the Reported-Domain: field is the reason the sender of the report chose to send it to you. The domain may be mentioned explicitly in the original message, or may be derived from it in some way. In cases where the derivation isn't obvious the report author is encouraged to clarify in the human readable section of the report." or something like that?

Cheers,
  Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 10 Feb 2010 12:26:34 -0800

> Sent: Wednesday, February 10, 2010 11:14 AM
> "The hostname in the Reported-Domain: field is the reason the sender of
> the report chose to send it to you. The domain may be mentioned
> explicitly in the original message, or may be derived from it in some
> way. In cases where the derivation isn't obvious the report author is
> encouraged to clarify in the human readable section of the report." or
> something like that?

If it's OK that I also say something like "therefore, general automated parsing based on the value of this field SHOULD NOT be done", I'm fine with that.

---

From: Steve Atkins <[email-masked]>
Date: Wed, 10 Feb 2010 12:38:31 -0800

> If it's OK that I also say something like "therefore, general automated parsing based on the value of this field SHOULD NOT be done", I'm fine with that.

No, automated triage is exactly what it's most useful for. It's almost a SHOULD rather than a SHOULD NOT. :)

If I'm a webhoster with 10,000 domains then the very first thing I'm going to do with a FBL is to choose something to key triage aggregation on - so I can route and report on incidents efficiently. An IP address is better than nothing, but the ideal key to use is the domain that's being reported.

It's the cases where it's not immediately obvious from the content of the original email why you received the report that the Reported-Domain: field is most useful - as it allows you to triage it and aggregate it with other reports about the domain in a way that you otherwise couldn't do.

So if there are 100 reports claiming to be about the domain, and you can mechanically identify why for 60 of those reports then you can do two things - a) treat the incident as one with 100 reports rather than 60 and b) treat the remaining 40 reports as "likely correctly categorised" rather than "need to each be handled manually".

Even more extreme, if you get 100 reports claiming to be about the domain and you can't mechanically identify why in any of them, you can still aggregate them into a single incident, treat that incident as one that's received 100 reports and then eyeball a couple of the reports as "probably representative of the 100" to see what's going on.

(I'm probably using some jargon specific to the way we use Abacus to handle high volume report streams, but the principle is pretty general.)

Cheers,
  Steve

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Wed, 10 Feb 2010 09:41:21 -0500

In <[email-masked]>, on 02/09/2010

>the original message's header.)

Does that imply that MARF should not be used to report drop boxes and
spamvertised web sites? The phrase "or related to" in 1.1 would suggest
that MARF is appropriate for that purpose.

-- 
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2        <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Wed, 10 Feb 2010 17:15:24 -0500

In
<[email-masked]>,
on 02/10/2010
   at 12:26 PM, "Murray S. Kucherawy" <[email-masked]> said:

>If it's OK that I also say something like "therefore, general automated
>parsing based on the value of this field SHOULD NOT be done", I'm fine
>with that.

I like that.

Would there be value at a later stage in defining fields with more
specific meaning, or defining optional flags in the existing field to
identify the relevance of the domain name?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 10 Feb 2010 14:56:02 -0800

> Sent: Wednesday, February 10, 2010 12:39 PM
> > If it's OK that I also say something like "therefore, general
> > automated parsing based on the value of this field SHOULD NOT be done",
> > I'm fine with that.
> 
> If I'm a webhoster with 10,000 domains then the very first thing I'm
> going to do with a FBL is to choose something to key triage aggregation
> on - so I can route and report on incidents efficiently. An IP address
> is better than nothing, but the ideal key to use is the domain that's
> being reported.

I guess I have a different idea of automation on receipt, namely immediate mitigation rather than just bucketing or sorting for human action.  If I'm in the minority though, then that's how it goes. :)

So about the text you proposed:

Can I get some +1/-1s or suggestions for tweaks?  I would prefer to include language like this to indicate why the WG felt the field was useful even if it is not fully formally defined.

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 10 Feb 2010 17:59:59 -0500

> Can I get some +1/-1s or suggestions for tweaks?  I would prefer to include language like this to indicate why the WG felt the field was useful even if it is not fully formally defined.

I was actually thinking of telling them to look at the original
message instead. Reported-Domain is really a way to flag something to
say "hey look at this". They should still consult and parse the
original email to be sure.

Yakov

---

From: Steve Atkins <[email-masked]>
Date: Wed, 10 Feb 2010 15:36:03 -0800

> I guess I have a different idea of automation on receipt, namely immediate mitigation rather than just bucketing or sorting for human action.  If I'm in the minority though, then that's how it goes…

Yeah, automated triage and automated mitigation and entirely automated handling are fairly different things, though closely related in some regards.

> "The hostname in the Reported-Domain: field is the reason the sender of the report chose to send it to you. The domain may be mentioned explicitly in the original message, or may be derived from it…

+1 from me. :)

> Can I get some +1/-1s or suggestions for tweaks?  I would prefer to include language like this to indicate why the WG felt the field was useful even if it is not fully formally defined.

Some of that is BCP material, I suspect. Some of the reasoning behind why it may be useful to handle reports in this manner is subtle and lengthy.

Cheers,
  Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 10 Feb 2010 15:38:53 -0800

> Sent: Wednesday, February 10, 2010 3:36 PM
> Some of that is BCP material, I suspect. Some of the reasoning behind
> why it may be useful to handle reports in this manner is subtle and
> lengthy.

My interest is just including something rudimentary to explain why we weren't more formal with the definition of this field, so that during IETF last call or IESG review they don't get to block publication based on that issue. :)

We do have in our charter some BCP/Informational work, and a more detailed treatise can, and probably should, be included there.

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 11 Feb 2010 15:18:09 +0100

On 10/Feb/10 23:56, Murray S. Kucherawy wrote:
> I guess I have a different idea of automation on receipt, namely immediate mitigation rather than just bucketing or sorting for human action.

IMHO, automatic action should only occur after the original message 
has been confirmed, e.g. a signature verified or a log matched.

> "The hostname in the Reported-Domain: field is the reason the sender of the report chose to send it to you. The domain may be mentioned explicitly in the original message, or may be derived from it…

There's a couple of points that that text doesn't clarify.

Firstly, the meaning. We could say that it is the helo-name, an rDNS 
PTR of the connecting address, or even an authenticated DKIM or SPF 
derivation _as opposed to_ being explicitly mentioned in the "From", 
"Sender", "Reply-To", header fields, or in the message body, which 
would be eligible for Reported-URI. Or the other way around. Both of 
those fields can be a reason for sending the report to the relevant 
abuse team.

BTW, the production rule in the draft currently says

  reported-uri = "Reported-Domain:" [CFWS] URI [CFWS] CRLF
                  ^^^^^^^^^^^^^^^

Secondly, the exhibit. Is it necessarily a hostname? DKIM and SPF may 
authenticate a domain. Is it allowed an IP address as Reported-Domain?

As an alternative proposal:

  "Reported-Domain" indicates the host that transmitted the original
  message. It may be the the RFC5321.HELO/.EHLO or the PTR resulting
  from an rDNS lookup. The name is formatted as defined in section
  2.3.1 of [DNS]. This name MUST have been verified using the "iprev"
  method defined in [AUTH-RESULTS]. In case no verification is
  possible or available, an address literal, in the format specified
  by section 4.1.3 of [SMTP], MAY be acceptable.

(BTW, shouldn't references used this way be normative?)

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 11 Feb 2010 15:29:16 +0100

On 10/Feb/10 15:41, Shmuel (Seymour J.) Metz wrote:
> In<[email-masked]>, on 02/09/2010 at 03:27 PM, Alessandro Vesely<[email-masked]>  said:
>>"relevant to the report".
>
> spamvertised web sites?

No. Just not in that field.

> The phrase "or related to" in 1.1 would suggest

Yes.

---

From: John Levine <[email-masked]>
Date: 11 Feb 2010 15:42:57 -0000

In article <[email-masked]> you write:
>> I guess I have a different idea of automation on receipt, namely immediate
>mitigation rather than just bucketing or sorting for human action.
>

I'm pretty sure you will find that current ARF usage is mostly or
entirely automated.  I know it is here.

Like Steve said, Reported-Domain: is very useful for identifying
domains that are doing something strange, even with its current
somewhat ambiguous definition.

R's,
John

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 11 Feb 2010 12:27:38 -0700

> original email to be sure.

Right!  I think this gets back to our original intent: the metadata is there to provide some hints/pointers that the ARF generator thinks will be helpful, but the ARF consumer still needs to apply their own internal logic to the original message to decide what to do.

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 11 Feb 2010 17:40:40 -0500

> Right!  I think this gets back to our original intent: the metadata is there to provide some hints/pointers that the ARF generator thinks will be helpful, but the ARF consumer still needs to apply…

Perhaps we need to make this explicit in the document

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 11 Feb 2010 15:05:22 -0800

> Sent: Thursday, February 11, 2010 2:41 PM
> To: J.D. Falk
> Cc: Message Abuse Report Format working group
> > Right!  I think this gets back to our original intent: the metadata
> > is there to provide some hints/pointers that the ARF generator thinks
> > will be helpful, but the ARF consumer still needs to apply their own
> > internal logic to the original message to decide what to do.
> 

I think that's really what I'm getting at.  It's awkward to define a field that has no rigid semantics without at least explaining why that was done that way and/or how it might be used despite the absence of such structure.

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 11 Feb 2010 18:07:00 -0500

> I think that's really what I'm getting at.  It's awkward to define a field that has no rigid semantics without at least explaining why that was done that way and/or how it might be used despite the…

I meant that we should probably write this up somewhere that the
intent of the fields in the second area is two fold:

1. Some carry data that cannot be derived from the original message
like the connecting IP or the MAIL FROM.
2. Some are pointers but the original message should be parsed.

Yakov

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 12 Feb 2010 09:03:32 +0100

On 11/Feb/10 16:42, John Levine wrote:
> In article<[email-masked]>  you write:

I can imagine it. However, I'd also guess that immediate mitigation is 
not carried out blindly upon receiving any ARF report. It may be worth 
to mention verification practices that experience has proved to be 
good or bad (for example, redaction breaks signatures, so it may be 
bad to check them.)

> somewhat ambiguous definition.

I sharper definition shouldn't worsen that. Does the definition I 
proposed in 
http://www.ietf.org/mail-archive/web/marf/current/msg00658.html break 
existing implementations?

---

From: John Levine <[email-masked]>
Date: 12 Feb 2010 15:19:21 -0000

> It may be worth to mention verification practices that experience
> has proved to be good or bad

That would be fine, if there are any such practices.  Since the vast
majority of ARF messages are sent through FBLs from known senders, I
would be surprised if there was a problem with fake ones.  But neither
you nor I know, so perhaps someone with more experience can inform us.

> Does the definition I proposed in

I believe it does.  People send what they think is relevant, which may
not be something you've thought of.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 13 Feb 2010 10:09:36 +0100

On 12/Feb/10 16:19, John Levine wrote:
>> It may be worth to mention verification practices that experience has proved to be good or bad
>
> That would be fine, if there are any such practices.

AOL suggests to insert an /opaque identifier/ to circumvent redaction. 
If cleverly designed, it can also confirm the message's origin. Does 
this subject belong to the ARF's RFC or to the accompanying BCP?

> Since the vast majority of ARF messages are sent through FBLs from known senders, I would be surprised if there was a problem with fake ones.

Correct. In this peculiar situation there is a small number of known 
operators. Did they subscribe to this list?

---

From: Steve Atkins <[email-masked]>
Date: Sat, 13 Feb 2010 08:53:40 -0800

On Feb 13, 2010, at 1:09 AM, Alessandro Vesely wrote:

> AOL suggests to insert an /opaque identifier/ to circumvent redaction. If cleverly designed, it can also confirm the message's origin. Does this subject belong to the ARF's RFC or to the accompanying BCP?

The details don't really belong in the RFC, though a mention of the concept makes sense.

I suspect there'll be some difficulty getting actual BCPs for it. There have been corporations who did their best to delete those opaque identifiers out of reports prior to sending them, to ensure the report recipient could take no action based on them, and then those corporations used that lack of action to justify blacklisting the report recipient. 

Given that, some report recipients are likely to be wary of discussing their approaches in a forum with a persistent, public archive.

> Correct. In this peculiar situation there is a small number of known operators. Did they subscribe to this list?

There's not really much point in crafting up a fake FBL report in order to implicate someone when you can simply send out spam that implicates them and wait for the inevitable result.

Cheers,
  Steve

---

From: "J.D. Falk" <[email-masked]>
Date: Sun, 14 Feb 2010 13:49:08 -0700

> AOL suggests to insert an /opaque identifier/ to circumvent redaction. If cleverly designed, it can also confirm the message's origin. Does this subject belong to the ARF's RFC or to the accompanyi…

BCP, if anywhere.  It's already in many non-IETF BCP documents.

> Correct. In this peculiar situation there is a small number of known operators. Did they subscribe to this list?

Some are, and we'll take care to update the others at MAAWG & similar conferences -- plus, of course, encourage them to join this WG if they're interested in participating.