Hi Hugo, On 6/1/21 4:19 PM, Hugo Salgado wrote:
2.) NSID option --------------- The draft says, RRSERIAL helps "recognize the origin of an answer" (supposedly when secondaries are out of sync).There already is a way to do that, using the NSID option (RFC 5001). It works as a part of another query, so no separate query is necessary (dig +nsid ...). The question here would be why another method for discovering the origin should be introduced.The aim is to recognize the "origin" of a response in the sense of "data source version". It's complementary to NSID because nsid allows to recognize the origin in "transport", or "server". They work in different scopes.
Sure, understood. I'd like to propose to use another word, as "origin" belong to the lexical field of "source", "ancestor" etc. and is misleading. A better word for the text may be "revision" or "version". Maybe even better, we could avoid the construct of helping "recognize the origin of an answer" altogether. For example, instead of
This "RRSERIAL" data allows to debug problems and diagnosis by helping to recognize the origin of an answer, associating this answer with a respective zone version.
we could just have
This "RRSERIAL" data allows to debug problems and diagnosis by associating an answer with its respective zone version.
This affects the abstract and the introduction. Best, Peter -- Like our community service? 💛 Please consider donating at https://desec.io/ deSEC e.V. Kyffhäuserstr. 5 10781 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
