Hi Tom, On 21.10.24 23:57, Tom Harrison wrote:
Thanks for clarification.Did the authors consider putting using RFC2119 language for that?Hi Pawel,On Mon, Oct 21, 2024 at 09:29:49AM +0200,kowa...@denic.de wrote: [...] In the absence of any text permitting partial implementation, this text requires implementers to implement the whole document ("the functionality specified in this document"). [...]
As far as the forward domain use case is concerned, the "/domains/rirSearch1/..." specification text can't be relied on as-is, because it's all in terms of reverse domains, and depends on their correspondence with internet number resources. If somebody wanted similar link relation searches for forward domains, then I think it makes more sense to define that in a separate document, rather than trying to generalise this document to support that use case as well.
This is I guess a bit the problematic part. Relation search seems to be as generic use case as reverse search and having a second specification on forward zones looks a potential burden for a generic client implementations. If the path part for the relation search would have been kept generic, like /domains/relsearch/ it could be extended by other documents to other relation types not specified in rir document. This brings me also to a conclusion, that an extension prefix would be rather harmful as it would pin the functionality and the path segment to rir extension, even if it would allow further extensions and as client one would expect the path to remain same.
Kind Regards, Pawel
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
