IANAbis at IETF 123 Madrid

Important URLs:
https://datatracker.ietf.org/group/ianabis/about/
https://datatracker.ietf.org/meeting/123/materials/agenda-123-ianabis-00

(Chair conclusions and action items in bold below)

• Chairs do administrivia
• Amanda on open questions on 8126bis
  • Carsten believes I-Ds should count
  • Barry says that whether I-Ds count should be part of the instructions to the Expert Reviewer (since spec required implies Expert Review)
  • Rich agrees but notes controversy
  • Paul notes that many current registries did not have instructions and Expert Reviewers are making the decision sometimes in opposition to what the WG might want/have wanted. Perhaps needs to be ability for the IESG can override.
  • Carsten indicates that if the WG does not say, then it should be up to the Expert Reviewer
  • Murray (as participant) notes that expiration of drafts is a problem. Ted (as chair) and Roman (as AD) say that this is out of scope.
  • Paul notes that this idea of WGs needing to specify what they want applies to the other bullets as well.
  • Shares Murray's concern about expired I-Ds. Also has concerns about Expert Reviewers end up empowered to make policy decisions. If they are going to do that, then those decisions need to be made publicly.
  • Peter notes that the judgement being made is about the availability of the specification. The Expert Reviewer should not make that determination. The WG needs to make clear what level of availability is needed.
  • Paul disagrees that this is a big problem; it only occurs a couple of times a year. Mostly, things work well.
  • Barry agrees that this is not a big problem, but the part about these discussions need to be had in public is correct. On bullet 4, they should investigate storing specs, but it's going to be non-trivial.
  • John thinks that current WGs have not been specifying the policies and Expert Reviewers are currently making policies. There does need to be public discussion to make sure that doesn't happen.
  • Carsten points out that this process almost always happens outside of WG auspices, and therefore making the WG Chair part of the process is not feasible.
  • Ted (summarizing and echoing Alexey from the chat) that this document should say that for future WGs, they needs to do the specification of what to do. Paul volunteers to write text to this effect. For existing registries that don't have the policy we should say something like, "The Designated Expert shall consult with the IESG to determine the correct policy." Rich volunteers to provide text. This will go to list to discuss.
  • Ted notes that for bullets 2 and 3, we address as above.
  • Barry ???
  • Mike reminds that for several registries there are mailing lists for discussions to keep things public. Ted notes that this should go into Paul's text.
  • Paul thinks that IANA should not be looking into storing specs. It would be onerous. There will eventually be a movement to have IANA to do this for many registries, making things worse. We should defer this.
  • (Further general discussion of IANA storing specs.)
  • Ted (as participant) explains that republication will be a problem for certain specifications
  • Paul ???
  • Barry - There needs to be an interoperable version of the spec at the time of the registration
  • Ted - Could at least have a pointer with a date, even if the target ends up being eventually inaccessible. Barry says this might be a reasonable compromise.
  • Mike - The registrant must provide a stable reference. That should be their responsibility. We shouldn't be on the hook to store.
  • Carsten - If it needs to be stable, it needs to be stable
  • Ted - The intention of the pointer is meant to be temporary. Mike says that's not the common case. Ted says that for the prospective cases, the WG needs to specify what should go into the pointer. Mike volunteers to write some text, but does not want overtly unavailable specs. Ted notes we have historically allowed those.
  • Rich is concerned about temporary references when the temporary state may go on for too long.
  • Peter - There's a difference between registries with code point scarcity and those that don't.
  • Murray (as participant) asks Rich whether things could be solved through provision vs. permanent. Answer: No, there are lots of registrations that will never change.
  • Paul says that we don't understand the need. We should first establish needs before making the decision.
  • Ted (summarizing): Whatever IANA does now in such cases is sufficient for the moment and we do not need to work on reference storage at this time.
  • Barry - Purpose of coming up with pre-packaged policies was to cover most cases. We should say that if you need more details, add them. We shouldn't come up with lots of variations on these. Alexey agrees.
  • Alexey asks what the "FCFS With URL" policy means. Amanda says it's basically a place to put the explanation.
  • Carsten agrees with Barry that we don't want too many of these.
  • Ted asks Barry to write text that would give examples without having to introduce new categories.
  • Paul on "Status" field - There be dragons, and we have little experience. Don't put anything in this document. We may have another document in the future to do this.
  • Barry follows on to Paul, noting that 8126 has a web page with further guidance. This belongs there, outside of the RFC.
  • Peter believes that doing the Status for DNS was a mistake. It's additional information that's complex, confusing, sometimes weaponized. We shouldn't do this.
  • Ted (summarizing) - This document should not say anything about "Status". Next rev of document should not mention it.
  • Carsten says "deprecated" means "this is going away" or "you should not use it".
  • Roman (as participant) - The current practices are haphazard. Roman agrees to provide some text.
  • Paul - "Deprecated" is used in different places through the draft. We need multiple definitions or get rid of the words as much as we do. Paul agrees to send text to Roman to address this.
  • Amanda - Regarding 13.3, it was originally suggested for 8407.
  • Ted (summarizing) - Given no comments on 13.3, it does not need any rewriting, and perhaps it should be struck and maybe moved to a separate doc later. Chairs (Murray) will check with Med.
  • Ted asks whether anything else is so trivial that it should be moved out of the document to online help. Nobody came up to ask for this, so nothing needs to be moved out.
• Moved to discussion of remaining documents. Ted wants to take draft-bormann first.
  • Carsten believes this could be the text for examples of variations on different policies and suggest we adopt it as standalone doc.
  • Ted suggests that that the 7120bis info moves out of this and that instead of Barry writing text for 8126bis he suggest updates for this draft.
  • Amanda believes we need some regularized names because there are lots of registries doing this. The 7120bis text in draft-bormann is already in the 7120bis document. OK with either putting the remaining text into 8126bis or just a pointer to this document, but a preference for 8126bis.
  • Ted asks whether anyone prefers the pointer method. Given no objections, the proposal is to roll the appropriate bits of draft-bormann into 8126bis.
• Discussing draft-klensin
  • John suggest folding this document into 8126bis as well.
  • Ted summarizes that draft-klensin be folded into 8126bis
• Dicussing 7120bis
  • Murray says that the call for adoption is long past and therefore 8126bis and 7120bis are considered.
  • Ted says that after the next rev is released, Carsten will confirm that his edits are in the document and 7120bis will go to WGLC.
• Discussing -early-registries
  • Carsten says that we need this, and soon.
  • Ted says that chairs will issue call for adoption.
  • Ted believes that WGLC will come quickly after adoption, so people should start reviewing during call for adoption.

End of meeting