<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 4, 2021 at 11:17 AM Dimitris Zacharopoulos (HARICA) <<a href="mailto:dzacharo@harica.gr">dzacharo@harica.gr</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
    Well, the idea was to do a Reverse lookup<br></div></blockquote><div><br></div><div>Right, that was the part not specified, but implied ;) That's the language-to-be-improved :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><blockquote type="cite"><div dir="ltr"><div class="gmail_quote">
          <div>It's also not clear to me the motivation of why. I'm
            hoping you can elaborate if there are more concrete
            arguments in favor other than "for consistency". For
            example, an explanation of use cases that are otherwise
            unmet without this change, particularly since it'll require
            careful language to ensure it does what I believe you're
            trying to do, but which is not yet specified to do so :) </div>
        </div>
      </div>
    </blockquote>
    <br>
    I consider this a secure method of contacting the entity that
    controls/owns the IP address space, just as the SOA can be used for
    forward Domain Name lookups as part of 3.2.2.4.2.<br></div></blockquote><div><br></div><div>Unfortunately, I think this introduces unintentional surprises into the chain, so I'm not sure it's unconditionally good. That is, the SOA is used for one set of semantics, and this would enable it for a different, and it's not clear that when the SOA record was established, that delegation (of TLS authority) was intentional.</div><div><br></div><div>The requirement to use the RIRs/LIRs unambiguously establishes a chain of authority to the "owner" of the IP address (i.e. without delegation). Introducing the added SOA semantics, particularly if a delegation event had occurred, might delegate authority otherwise unintended. Using "a new record" could resolve the ambiguity (by having a strong, explicit signal of delegation of TLS authority), but that's a non-trivial amount of work :) That's why "consistency" alone wasn't a very compelling thing, and I was trying to figure out if the delegation beyond the RIR/LIR level was intentional.</div></div></div>