Minutes interim-2022-edm-01: Tue 12:00
minutes-interim-2022-edm-01-202202011200-00

# 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