Jenny Bui (IETF Secretariat)
Ignacio Castro (RASPRG Chair)
Liz Flynn (IETF Secretariat)
Kurtis Heimerl (GAIA Chair)
Colin Perkins (IRTF Chair)
Melinda Shore (At-Large member)
Allison Mankin (At-Large member)(joining at the end)
Brian Trammell (PANRG Chair) (joining at the end)
Carsten Bormann (T2TRG Chair) (joining at the end)
Colin brought up chatting about the travel grants during the discussion topics.
The minutes of the April 30, 2024 IRSG Teleconference were approved.
o Colin to follow-up with Sofía about drafting text for guidance to IRTF document shepherds
o Melinda Shore to draft text for guidance to IRTF document shepherds
Colin followed up with Sofia, and said Sofia is not able to provide text for this. Colin then asked for volunteers.
Melinda responds that she can help with this, and asks if it needs to be written as an Internet draft or just a few paragraphs.
Colin says that a few paragraphs then the document will be in the wiki to give people guidance for what to write in teh document shepherd.
o draft-irtf-hrpc-guidelines
o draft-irtf-qirg-quantum-internet-use-cases
o draft-irtf-cfrg-frost
NONE
NONE
o draft-irtf-cfrg-kangarootwelve
o draft-irtf-iccrg-rledbat
o draft-irtf-nmrg-green-ps
https://docs.google.com/spreadsheets/d/1KN2-I23Ccc5uFGAwOdjdyNhEXBd1GswC0xAIQKUaPhk/edit?usp=sharing
Jenny asked the group if they preferred the IRSG dinner to be walking distance or somewhere a bit further, about 15 minutes by car but will have better dietary options for others.
Colin mentions that previous places have not been so great with accommodating to vegan dietaries so it might be better to reach out to the new recommended restaurants to see if they have availability.
Jenny will reach out to Pidgin and Acorn to see if they have availability.
Ignacio brings up that the deadline is today, and has been chasing people for some missing items. Nick Feamster may be the keynote speaker, but Ignacio will need to confirm again.
Colin agrees that he is a good choice.
Ignacio asks for the ANRW date.
Colin asks Liz.
Liz chimes in and says that the alldispatch experiment is most likely happening on Monday so Tuesday might be a better choice for ANRW.
Ignacio responds that Nick is available in the beginning week (IETF week) but not later.
Colin asks if Ignacio has a feel for how many papers are likely to get accepted?
Ignacio responds that it is hard to say.
Colin says that there needs to be a balance enough to get a decent program without having too high an acceptance rate.
Colin then asks if we received the approval paperwork from ACM?
Ignacio responds that he has not seen it.
Jenny reminds everyone that the session request cut-off is next Friday, June 07. An email reminder will be sent out next week as well.
Colin asks when is the agenda deconflicting call?
Liz responds that the call will be on June 20th.
Colin gives an update that travel grants announcements have been delayed since the budget is still being worked on. We switched to paying the hotels for awardees directly a year or so back because it was getting to be a bit of a nuisance of having the awardees book it then we reimburse them. However, there's a bit of confusion as the hotels were coming out of the IETF budget but we should pay them out of the travel grant budget. Colin has not seen the final numbers of how much that has been costing so we're not sure how much money is left in the budget. Also, the Brisbane Economic Development agency still hasn't finalized how much money they're giving us, which leaves things up in the air.
Jenny responds that is the extent that she knows as well. Also, that Debbie and Laura are working internally on that, we will probably hear more about it when Debbie comes back from PTO tomorrow.
Colin adds that Jayasree will definitely be awarded and that we should use the ANRW comp code for their registration.
Jenny responds that she will send the grant announcement for Jayasree.
(Carsten joins the call)
Colin asks Carsten about the T2TRG interim in Paris.
Carsten responds that the meeting was very good. The whole Hackathon context was very good context. There were about 40 people there, and 20-25 people at the interim meeting. There were 5 interesting talks, so it was definitely worth doing.
Colin asked if they ran out of time because there's a follow-up interim scheduled.
Carsten replied that they had 8 proposals so they had to push some off to the next meeting. They managed to get a bit of thematic split so the interim will be a slightly different subject.
Colin asked if it's an online meeting?
Carsten replied yes it is, but that he wouldn't mind going to Paris again.
(Allison joins the call)
Colin mentions to Allison that the call has been fairly quiet unless Allison is willing to volunteer to read Crypto Forum drafts.
Allison responds that she is hesitant to volunteer, but asks if there were no volunteers?
Colin responds that there are volunteers for that one, but there's a couple more coming which are congestion control and green problem statements. That might be something Allison prefers to review.
Allison says she'll be happy to do some reviewing.
Allison asks about a discussion about Crypto Forum and its status that was happening on the TLS or LAMPS list, and if that is a topic that Colin plans to take up? Whether there's more regularization to do CFRG with respect to working groups?
Colin responds that it was something he wasn't really happening on talking about much. Whether CFRG should be part of IETF or how it relates to IRTF, comes up fairly regularly. Colin thinks that if we move it too much from where it is, we're likely to disrupt the crypto panel and set of academics that participate there. Having that working well is much more critical than having it perfectly aligned with the way the IETF or IRTF work.
Melinda chimes in and says it seems like the questions that have been raised are mostly about IETF processes rather than IRTF specific.
Allison adds that the one thing that occurred to her is that without changing in any way the governance of the panel, the panel could also report to the Security Area or like the General Area. It could be a directorate as well as a panel. From the point of view of all the great academics who are on the panel, nothing changes, but from the point of view of some of the IETF chair or Security ADs, they have a little more cover when the panel says something. It may not be worth doing that as it's kind of weird.
Colin says that it would put it in a slightly weird situation and he would worry that the panel members wouldn't want to get that heavily involved in the IETF side of things.
Allison agrees that Colin is right, and that she thought she should ask. It comes up all the time; it's an evergreen topic.
Brian says he is a little confused as to the problem they would be solving by doing this? People are in this weird fuzzy middle space, like that's what research groups can kind of be for. That's why we have the freedom over here. Is there a concrete problem that's trying to be solved other than it's a process weirdness?
Allison adds that it was a thread that was on LTRU, and she brought it up without properly preparing her brain right now but one way to do it is for example, the congestion control research group has a companion working group. Allison isn't sure if there's enough talent to actually have the companion working group to CFRG but maybe. It was a really lengthy thread on the LTRU. Allison also adds that this usually gets resolved by people saying they know they're doing the right thing, so let's try not to mess with it. Allison says that she's not trying to mess with it either but since it comes up all the time, it might be worth having a long range plan or having a long range plan to never change anything and making sure that's clear to people.
Colin says he thinks that a lot of it is the way the IETF interacts with Crypto Forum and the Crypto Panel, which often tends to be phrased as the crypto panel or crypto forum is going to decide this rather than CFRG is producing some specs and then the IETF decides that those algorithms meet its needs and incorporates them into its standards. The situation is always a bit fuzzy because it's a very spec oriented research group.
Brians adds that's fine though, right? Because the CFRG is a place where you can essentially get a stamp from people who know what they're talking about. The people in the Security Area who are making decisions as to whether something or not is going to be recommended for use in an IETF spec have other considerations beyond this algorithm does what it will say on the ten.
Colin responds that part of the reason it gets complicated is that some of the IETF specs have particular crypto needs and so it ends up saying, you know, if CFRG should design an algorithm to do this.
Brian says that people on the IETF can certainly refer work to the IRTF and the IRTF can choose to pick it up or not.
Colin adds that this looks awfully like the IRTF is then producing a standard to do something.
Brian says that if the IETF needs a standard crypto thing that doesn't exist yet, it should form a working group to create that and then send it over to the CFRG to check to make sure it does what it doesn't.
Colin adds that it's not what actually happens.
Brian says that he now sees the concrete problem that we're trying to solve.
Allison chimes in that there's also the problem of a group that says they want to make an algorithm mandatory to implement, but it's not one of the ones that CFRG thinks is a good one. So that can happen too. Then there are differing opinions and the standards people have the final say on this. Allison doesn't think that bothers CFRG people, but it bothers the process people.
Colin adds that there is a parallel discussion happening, about the ISE handles national crypto algorithms and how they use the crypto panel. The ISE and IAB are going to have a session in Vancouver to talk about this.
Colin's proposal is that it's best to leave CFRG alone since it seems to be working but there's always tension there.
Brian adds that if this keeps being a thing, does the IRTF Chair make statements? Or would it be an IAB statement that would? Brian thinks it might be an IAB statement as sort of like the oversight body for this whole thing. CFRG, is the body for reviewing the details of crypto, the IETF can mandate the use, mandatory to implement of certain algorithms in a thing, and that's what these are for. Having a statement that people could refer to and say, this is the intent. We can talk about it, whether that should be the intent. We can talk about fixing things if the state does not match intent, but it doesn't seem like state matches intent here. The ISE vanity crypto thing is separate.
Colin says that is a separate but related conversation. The crypto panel sometimes gets pulled in to review those.
Brian then adds that we're never going to be able to keep people from getting an IRTF RFC and then misrepresenting that in the market. There's no appetite in the community to change how the RFC system works in order to fix that.
Colin asks if Brian has been on the RSWG list recently?
Brian responds that his reward for not having to chair that working group was to not read the list.
Colin understands that, but that there is certainly an appetite to change how things work.
Brian says he'll go check the archives.
Allison asks which mailing list?
Colin responds, RFC series working group.
Allison asks if that's an open mailing list?
Colin says yes, it's an open mailing list. The list is mostly arguing about details of the XML format. Every so often they turn around and there are proposals for making things more or less immutable in the published RFCs.
Carsten chimes in and says that there is actually an one hour meeting scheduled for tonight.
Allison asks if Colin has already covered the question that he asked the group about what they thought of the changes to the RFC updating process? Colin has sent mail out saying it affects RFCs.
Colin responds saying that he did not bring that up. He figured if people had comments on it, they would reply to the email but we can certainly chat about it.
Allison thinks it's a little unsettling. She doesn't know what the oversight is going to be to make sure that there aren't technical changes introduced by that process. But it's more important for the standards folks than for the research folks.
Colin says that it's mostly documenting what has been happening and giving the RPC the ability to make some technical changes to the format rather.
Allison thinks that they don't have immutable RFCs now, the only thing you can do is add erratas and they're saying that we can actually change things in the RFC.
Colin thinks the intent is that there's been bugs found in the XML format and problems with the PDF generation and they want to be able to regenerate the sort of output format and fix bugs in the XML that does not affect the content.
Carsten chimes in and says that those are two different things. One question is, should we actually be able to change the, so called, authoritative or canonical form of the RFC which is the XML since RFC 8650? And the other one is should we be able to render into an HTML text and PDF, and the latter is already happened because there have been pretty bad problems with the PDF generations but there's also have been problems with the CSS that supported the HTML. Carsten think it's pretty clear that we want to do that, but doesn't think we haven't really found an answer to the question: what do we want to change in the XML and what is the change that isn't a change? Carsten thinks that that will will go on for some time. The concept of the immutable RFC isn't entirely dead yet.
Allison adds that there is a section at the end of the document which says, and we don't have a really clear boundary so we don't know exactly how we're going to prevent things that unintentionally change the technical content here.
Carsten says that has happened already because the one thing happened is that the RFC editor, RFC repeatedly changed the semantics of the XML, so the XML is still saying the same but the output it now different and that creates some problems. Carsten thinks we haven't really modified the meaning of an RFC too much yet, but it certainly is harder to read in some cases now. That's another danger that we have a canonical form but we're changing the meaning of what that technology means and thus we're changing the RFC.
Colin adds that his understanding of where we're at, is that we're at the level of having XML encoded and what it means and fixing that and fixing the renderings. There has been discussion as to whether RFCs should be non immutable in terms of contents, but that hasn't been decided yet. The current discussion is about keeping content the same but keeping the XML format to fix problems with it, for example.
Colin asks Carsten if that is right.
Carsten responds yes, there are definitely bugs in the XML grammar in the vocabulary of what you can put into what. That is highly broken in many places, but the fix for that would be to extend the set of valid instances. The fix does not necessarily mean to take out parts. Then there are parts like for instance, the postal element that relied on some idea of semantic mark-up that unfortunately is no longer supported by open source components we might be able to use. There is a certain technical pressure to fix this in some way or the other. That would actually raise the question, do we have to modify existing RFCs by removing the post element by simplifying it in a way we still can support it in the long run. These are two different questions.
Colin agrees, but none of them are focused on the technical content of the RFCs. They're focused on the XML format and questions around that.
Carsten agrees, but the XML format limits what you can say.
Colin responds yes, there's discussion about it but none of the proposals are let's have living RFCs and allow the technical contents of a published RFC to change. It's about fixing the XMl format.
Carsten says that we know a number of people in the RSWG want exactly that to happen which does modulate the discussion a little.
Colin agrees that some people want to have living documents. The discussion hasn't agreed that should be a thing yet. The current proposals are much more limited to sort of details of the XML format. Colin adds that his feelings for the RFC 7990 updates document that is being proposed there makes sense. There are bigger changes potentially coming down about non immutable RFC and living documents. Colin thinks what we currently have makes sense to him. If people disagree with that, then let him know and he can reflect that in the approval process.
Allison thinks it was helpful to get more context because certainly there's a reference to the broader stuff in the end of that document. But the document itself, Allison does agree that it did not seem to be about living documents. It kind of hinted at that direction at the very end. It's kind of a security consideration so that's reasonable.