# Minutes - EDM call 2022-02-01

## Chair introduction

* Agenda: https://datatracker.ietf.org/doc/agenda-interim-2022-edm-01-edm-01/
* Chair slides: https://datatracker.ietf.org/doc/slides-interim-2022-edm-01-sessa-slides/

## Implementation status survey & next steps for implementation status

* Paul Hoffman asking about how implementation status is surfaced to WG members. As an example in DNS, conformance/interoperability tracking was done for a while but it came as a surprise to many - whereas in HTTP it's commonplace. It would be useful to make this best practice known to folks IETF-wide
* Tommy Pauly: Maybe we write an IAB document on recommending this practice, mwe link this from the datatracker to help raise awareness
* Paul H: Maybe this is best done by the IESG, or maybe even just a blog post
* Tommy: Agree, we could do both?
* Eric Vyncke: We should target a specific protocol, e.g. tracking all IPv6 would be too much, but maybe only new implementations? And IPv6 conformance is way too hard
* Luigi Iannone: To follow on example, how long do we need to track implementations of IPv6? Forever? We have so many. Some protocols keep evolving but not all.
* Tommy: This matters more during standardization compared to after the fact
* Paul Wouters: We remove the implementation status section when publishing RFCs to avoid it becoming an advertisement for first implementers
* Charles Eckel: two purposes for this: (1) during protocol development, but also (2) after the fact as a useful resource for folks wanting to start a new implementation as a test tool, or to sniff traffic. Making this easy to find would help a lot
* Robert Sparks: What life cycle do you have in mind? I see this being useful early in development but after that these lists become popularity contests or graveyards after a few years - so who is the tracking for? Implementers that are just getting started can use this, but will new implementers of old protocols still benefit from this?
* Charles: Yes, having this live on can be useful even if it's no longer updated frequently. A list of links provides more benefit than harm even if some are no longer maintained.
* Alexey Melnikov: +1, stale information is still valuable
* Paul H: Back when VPN consortium was active, we used this for conformance testing. It was a marketing factor, and that's good. It helped push IPsec vendors to correctly follow the spec and implement extensions
* Alexey: same for IMAP
* Robert: Do we need to normalize how WGs capture this information? Right now the datatracker allows adding any links to the "additional resources" section. We don't have a good wiki solution in-house right now but GitHub is widely used. There was talk about creating a custom tool here (was it maybe called codematch?) but maybe just using existing tools is enough
* Tommy: From discussion on list, that custom effort fizzled out, it's more important to have a standard pointer than having a common way to host the list, at least initially. That's the direction we want to go in.
* Andrew Campling: Suggest not building a new tool, there are plenty of existing ones. BUt maybe suggest one, choice isn't always good
* Tommy: Providing options is great, but we don't want to force WGs to change what they do. Concretely, should we define a new datatracker additional resource tag?
Robert: There are plenty of existing tags but adding a custom one for this would not be hard to do.
Tommy: Where does this metadata show up? Might be great to surface in rendered HTML documents?
Robert: Adding this to the top like other links today is easy, embedded deep in page would be hard. Currently, HTMLized text is "doc + metadata" whereas rendered HTML is only doc.
Tommy: Can we change that?
Robert: it's just about where we want to put our energy, and whether we want this to be discoverable by search engines
Luigi: What if we had an additional tab in the datatracker for implementations? Ideally something that various WG contributors could add to, not just chairs. Not sure what format that page should have. This could get more adoption than just chairs.
Robert: Small changes best for now
Tommy: Thinking about this direction is good, but maybe aim smaller for now. Additional resources can only be changed by chairs for WG page and WG documents, but individual contributors can edit that on their individual drafts, sounds like the right access control
Charles: This isn't necessarily per-WG but maybe per-draft, at least for some WGs.
Tommy: Since we can add this additional resource on both WG and drafts, that allows both modes of operation.
Eric: Tag is easy to start with. What happens when WG is closed? Who updates the tags then? And when do we remove this information? All this can be solved
Tommy: For now maybe this is a feature more than a bug, since we know this might become stale after WG closes. What happens after closure on datatracker?
Robert: closed WG pages stay and only IESG can modify pages
Tommy: I propose we bikeshed the name of the tag and then pick some candidate early-adopter WGs, and Charles please make this known during hackathon
Paul H: I suggest that the IESG could create these. In DNS, DNSOP is the default WG but many of protocols that would benefit here are not in DNSOP, so an AD could create a page for them.
Tommy: Maybe we need cross-WG pages
Paul H: Some individuals have done this in the past, ADs just need to put it somewhere official
Tommy: Charles, since codematch didn't work, does this new solution sound useful for the hackathon?
Charles: Yes I can (ab)use this tag
Tommy: Can you recommend folks use it?
Charles: Absolutely, we'll need the tool to explain what it does so folks know to use it. What's our plan for experimenting with this? Something before next IETF, maybe use at the hackathon?
Tommy: Yes, let's figure out the name of the tag and get it added by Robert and then Charles can mention it in the hackathon to have folks try it out. IAB can also work with IESG to inform WG chairs that this exists

## Plans for draft-iab-protocol-maintenance
* Martin Thomson: I don't think there's universal agreement that the philosophy in this document is applicable to all protocols. Portions of the community agree with the thesis though: protocol maintenance can remove the end for the robustness principle. Not sure what to do to balance this, need help with the other aspect
* Robert: let's discuss within this group. We should have focused discussion on this and figure out where this applies so we can eventually publish. Do we have a measure of which sub-communities of IETF agree with the thesis of this document. Perhaps seeing if it correlates with how many distinct players are in such a sub-community.
Eric: I haven't read the draft. This doesn't apply everywhere such as never-updated IoT.
Tommy: we need to figure out where to draw this line. Extremes are clear but middle isn't obvious.
Martin: Carsten mentioned the need to update vs the facts on the ground - many devices never get updated. We have an understanding that to be on the Internet you should get updates, but not everyone does. Similarly, there are industries where pace of deployment is much slower (e.g. routers) because of how impactful a mistake could be. I'd suggest ruling IoT out of scope because if they don't want to update their software they don't get to participate
Tommy: one motivation for the robustness principle is future developments to the protocol that you might not be aware of at the time of implementation. As we discussed in use-it-or-lose-it, being strict doesn't preclude extensibility. Implementations just need to know what can and cannot change.
Martin: if you design extensibility clearly, you can be conservative. Conversely HTML is an aggressive interpretation of the robustness principle as it handles errors permissively, but it now has a strict protocol. Whereas IoT that doesn't plan on updates doesn't need to make things extensible.
Mirja Kuehlewind: this is about protocols, not implementations.We should let folks know that protocols will evolve more than they did in the past.
Martin: the core realization I had while writing this is that protocols and implementations go hand in hand: you can't update one without the other. This made TCP stagnate for 30 years. That's not necessarily a problem
Mirja: so the draft should say that we should be more active to avoid that
Martin: that was my intent, but we can improve the text to say it better
Paul H: DNS has been like TCP here - let's do everything in extensions instead of changing the base protocol. I think the draft used to say this better, we need to surface the call to action that protocols need to evolve
Martin: Happy to do that, who can help?
David Schinazi: I have time, I'll help