Sounds good - 

In my configuration, the intent of including the key in the 'also-notify' section in a view on the master server is so that the notify messages being sent from master to slave correctly tell the slave which view needs refreshing (by tagging the notify with the view's tsig).  It appears to work as I expected, however it's possible something else in my configuration is causing the correct behavior and including the key in the 'also-notify' is superfluous.  

It was curious that with the latest version if I put the IP address of the master (rather than the name) in the also-notify, the 'key xxx' was allowed, so there's a little ambiguity in the current behavior, aside from the documentation maybe being incorrect.

Anyhow, thanks again for the feedback -

Cheers,
Simon.

-----Original Message-----
From: Evan Hunt via RT [mailto:bind9-confidential@isc.org] 
Sent: Tuesday, July 11, 2017 5:52 PM
To: Simon Ferrett
Subject: 9.11.1-P2, 9.10.5-P2 - "key" option for also-notify/masters broken when using masters name [ISC-Bugs #45495]

This appears to have been introduced in commit aa49af836, which added
a correctness check to also-notify clauses that hadn't been there before.

What I haven't worked out yet is whether the code is correct and that 
also-notify statement is invalid (in which case the doc should be fixed),
or whether the also-notify statement is valid and the code is being overly
restrictive.  The fact that it was accepted by earlier versions of named
doesn't necessarily mean it was working correctly at the time.  I'll keep
looking.