Hi Pawel,
On Tue, Oct 22, 2024 at 08:51:32AM +0200, kowa...@denic.de wrote:
> On 21.10.24 23:57, Tom Harrison 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"). [...]
>
> Thanks for clarification.Did the authors consider putting using
> RFC2119 language for that?
No, but we will add some text to make it clearer, since it's only an
editioral change (will upload along with any subsequent feedback that
we get during the rest of the process).
>> 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.
Generalising reverse search makes sense, because it works in exactly
the same way regardless of the underlying object types. Relation
search is not in the same category, IMHO, because the exact behaviour
of a given relation for a given object type is not a function of the
relation alone. For example, up/top/etc. don't have obvious
implementations for entities. As far as path consistency goes, the
client will still have to have foreknowledge of all the relation
searches that are supported anyway, so whether those searches are at
path A or path B doesn't seem like something that would cause much of
a problem implementation-wise.
-Tom
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
