Use HTTPS RR for Bootstrapping and NOT SRV RR (#56)

[mwullink]

No description provided.

[mdavids]

Review:

• Suggest to leave out TTL (3600) in the example.

• Consider @ and @ORIGIN example. in the example, instead of example. .

• In theory example. might have it's own HTTPS record already, which is not referring and unrelated to RPP.

  • Has an underscored label (like _rpp.example.) been considered?
  • Has SVCB been considered? Why HTTPS? See par. 10.4.5 and Appendix B to check if that is even possible.

• What will Alt-Svc: of the actual RPP server return?

  • And how does this align with this concept?
  • Should rpp.example. also get it's own HTTPS RR ?
  • Par. 9.3 of RFC9460.

• The following statement seems not in line with RFC9460, par. 2.5:
  "The client MUST ignore HTTPS resource records with a TargetName of . (service not available)."

  • Suggestion: leave out that entire paragraph, because it is only (incorrectly?) duplicating what is already in RFC9460.
  • Also; if 'service is not available', it's probably better not to add the HTTPS record in the first place.

• The following does not seem unambiguous: "The client MUST use either the IANA registry for RPP servers or a DNS lookup using an HTTPS resource record as defined in [RFC9460]"

  • For example: what if there is no IANA registry and the clients wants to use it?
  • MUST an HTTPS record be published, if there is also an IANA registry?
  • What if both exist, but are in conflict?

• Why not name it https:///.well-known/rpp.txt or rpp.json ?
  - IANA Considerations: add this well-known URI to the registry: https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml

[jasdips]

Looks good.

[pawel-kow]

Seems that some folks have a very different opinion as to whether HTTPS RR type is appropriate for service discovery.
https://mailarchive.ietf.org/arch/msg/art/4VGJ7ZthFs6w7mnO68JcXgIY-WU

Ben>> Drop the HTTPS record mode. "HTTPS" records are for improving the
bootstrapping of HTTP connections, not for identifying affiliated services
that happen to use HTTP. Using a TXT record here may be ugly but at least
it matches the common practice in email world (DKIM, SPF, etc.). We can
also define a new RR type.

I agree. HTTPS is for connection specification, not identification or
discovery. TXT always works. New RR type is a deadend.

[mdavids]

Perhaps a silly question, but why did we decide to move away from SRV again?

[mwullink]

the functionality described here is similar to what is used in rfc9461 for DoH
its a mapping of RPP svc to HTTP endpoint.
see: https://datatracker.ietf.org/doc/html/rfc9461

we moved from SRV to SVCB/HTTP because ow review comments see:
https://mailarchive.ietf.org/arch/msg/rpp/MXLcPctYwKVsT_k6rK-8l9Rk_0s/

i feel HTTPS is still ok for using rpp svc endpoint mapping