> On 20. Aug 2022, at 03:29, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > > Signed PGP part > > 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.
a question from our side of the fence: How would addition to the registry look like in practice? Would we add this to our "IANA" section in the draft? Or would we write an email directly to IANA "out of band"? I guess that latter as how would others (without IDs) do the former, right? If so, when? As that would likely affect the wording in any future updates. In general, and I assume unsurprisingly, I am happy with this version of the alt draft. Of course, I would be perfectly fine with requiring an RFC as well as this is within immediate grasp for us. But, I can also see the issue with setting the bar too high and risk having this ignored by others. BR Martin > > Cheers, > S. > >> W >>> Cheers, >>> S. >>> > <OpenPGP_0x5AB2FAF17B172BEA.asc> > > >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
