Re: [dispatch] Proposal for scantxt; scanning opt-in/out, identification, verification, notification, and reporting

[Ollie IETF <[e-mail]>]

> Based on my past experience of scanning, generally the folks in an org who legitimately ask for a scan aren’t the people who administer a given system.
> The day-to-day maintainers of the target system probably won’t be warned (and shouldn’t be) of a red-team exercise.
> Likewise the ‘results’ will go to the infosec department, rather than the local firewall folks.

There's quite a subject to get into here but I think you hint at cultural issues that standards like this should aim to help fix and not perpetuate those problems.
In my view the primary target of 'results' should be those responsible/accountable with running the service and the infosec team would likely want to have oversight (and create the mechanisms to get issues to the internal teams). 

> You certainly don’t want them to be able to say ’this is off limits’ because a) it would defeat the purpose of a pentest b) it would act as a red-rag-to a bull
> for all hackers of any persuasions.

I do agree with that risk so I'm leaning to remove the allow/disallow aspect and instead just have a standard approach to opt-out from an individual service.
e.g.: scantxt.app._scan.scantxt.org IN TXT "v=SCAN1; p=opt-out;" 
That said, "*._scan..." could be possible but as suggested in another reply, the intention here is to signal to legitimate, transparent scanners; I'm under no illusions this would do anything for people with a malicious intent.

Ollie