Hiya,
On 20/08/2022 01:55, Warren Kumari wrote:
On Fri, Aug 19, 2022 at 5:46 PM, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:Hiya, On 19/08/2022 20:43, Warren Kumari wrote: So, it is perfectly acceptable (in my view) for it to have: Reference Name --------------------------------- a-cool-document foo.alt another-document foo.alt yet-another-doc bar.alt I agree that such duplicate names are acceptable in this registry. I scanned the draft quickly and think it's good. (I'll try do a closer read in a few days.) Only thing with which I'd argue for now is that I think RFC required is a much simpler rule for the registry.My concern with this is that we may end up with lots of Internet Drafts which either need to be put in some WG or be AD sponsored, and have to go through IETF LC, and IESG Eval, and use RFC Editor resources and similar. For an informational only thing that seems like a lot of overhead. I'm also not very sure that IETF participants would really want to review yet another block-chain based name resolution system every N weeks…
I agree wrt IETF review. My possibly wrong assumption was that most drafts looking for names in this registry might arrive via the ISE or IRTF, with few desiring all the fun of IETF processes. I guess I'd generally be ok with there being non-trivial hoops that need to be jumped-through for this registry, but yes, I know that increases the chances of squatting-like behaviour. I also recognise that reasonable people might make different predictions about this small bit of the future.
Any other option will require some designated experts with some guidance for those DEs, and I'd expect it to be hard for us to agree what guidance to include in the draft or not, and I'd expect it to be hard to find DEs for this registry.Yup, that's a valid concern - IANA's site speaketh thusly: "If you choose Expert Review or Specification Required as the registration procedure for your new registry, it can be helpful to provide guidance to the “expert.” The idea is to provide the expert with guidance on naming, allocation and other issues related to the protocol registry. Sometimes Internet-Draft authors include the guidance directly in the draft. Other times, a Working Group will decide to collect guidance for a group of protocols together (for instance, see the PWE3 working group in RFC 4446)." — https://www.iana.org/help/protocol-registration I'd think that the guidance to the experts would be: 1: Is there a specification somewhere? RFC8126 (Spec Required) says that a specification should be a "document can reasonably be expected to be findable and retrievable long after IANA assignment of the requested value."
Right. It's the "long after" and stability (for some random project) and sufficient detail (for academic pubs) I wonder about for the specification-required path. (I've no worries about the IESG approval path.) I figure we might be better off seeing how an RFC-required setup pans out for a bit, then, if it seems right, loosening that to the point where some DEs can ok adding entries after we've figured out what guidance to provide to those DEs.
2: Does it list a name that they'd be using? Great, done! [ insert the Oprah Winfrey "You get a registration and you get a registration" meme here — https://knowyourmeme.com/memes/oprahs-you-get-a-car ]. It is intended to be an informational registry to help people avoid conflicts, and potentially also figure out what to read to know more about foo.alt - IMO they can be handed out like candy. It's better to have it easy for people to get added than just squat… The current IANA Considerations bit says "Expert Review" or "IESG Approval" — the second bit is specifically incase there are issues with getting DEs…That said, I'd still be ok with progressing the draft if the registration rules stayed as they are now.Thank you - the registry is something I've gone back and forth on, because there are pros and cons…
Sure - if it's only me arguing for RFC-required, then I'm fine with being in the rough on that aspect. Cheers, S.
WCheers, S.
OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
