On Mar 20, 2023, at 1:43 PM, Wessels, Duane <dwessels@verisign.com> wrote:
- SHOULD respond to queries that include an NSID [RFC5001] EDNS(0) option with an identifier that is unique for each instance. At the time this document is published, each root server operator deploys multiple instances, so the instance identifier for the NSID response SHOULD include a sub-string that identifies the root server operator. The identifier is only useful for debugging and does not necessarily indicate any attribute of the instance that is responding.
The wording here is a bit stilted because BCP40 does not yet define "instance", does not yet talk about anycast, and doesn't even really define "root server operator". If those are addressed before the document is finalized, the above wording can change as well.
Thoughts?
IMO we should probably avoid “instance” here, and maybe “unique” as well. It will lead to a discussion of instance vs site vs server that won’t be fruitful. In my proposed text I was careful to avoid that.
Your proposal was: MUST implement the Name Server Identifier (NSID) Option [RFC 5001] and SHOULD set the NSID payload to a string that conveys the server's geographic location. I used "instance" because "server's" is not clear because the base document uses "server" to mean either the RSO or (apparently) the hardware. I suspect this is because in 2015 not all the RSOs were using anycast. I also find "conveys the server's geographic location" as over-specific. I have heard that some RSOs don't like doing this, and I certainly know that there are sometimes errors when they do.
I find the second sentence (“At this time…include a sub-string”) somewhat confusing. Generally I think “at this time” comments aren’t really relevant. The RFC should just say what the recommendations are.
I thought it was relevant because 7720 didn't acknowledge anycast, and the use of NSIDs is only relevant because of anycast.
But I also don’t see what RSOs having multiple instances has to do with the sub-string, and I think you mean root server identity there instead of RSO?
It would help the person holding the NSID. I can easily imagine two RSOs having the same identifier such as "LAX-1".
What goes into the NSID payload is less of a protocol recommendation, and more of a policy recommendation/expectation.
It falls into the category of Deployment Requirement. I'm fine with having different wording that somehow indicates that each "server" (hardware) have a different NSID, but I think that requires rewriting the top of the document as well. It sounds like we should do that. --Paul Hoffman