Carsten Bormann (T2TRG Chair)
Jenny Bui (IETF Secretariat)
Ignacio Castro (RASPRG Chair)
Laurent Ciavaglia (NMRG Chair)
Jana Iyengar (At-large member)
Stephen Farrell (UFMRG Chair)
Liz Flynn (IETF Secretariat)
Dirk Kutscher (ICNRG/DINRG Chair)
Dave Oran (ICNRG Chair)
Colin Perkins (IRTF Chair)
Brian Trammell (PANRG Chair)
Lixia Zhang (DINRG Chair)
The minutes of the September 24, 2024 telechat have been approved.
Colin: It looks in reasonably good shape to me, so maybe a couple things to sort out but it’s pretty close from what I can tell. Please do take a look and I guess send some comments to Melinda or raise issues on the repo if there are things you cannot write in there. It would be good to get that finished soon because Melinda has retired and is stepping-down from the IRSG so we should get that finished before she goes.
Colin: Nothing to say there, I think it’s all good.
Colin: The Code of Conduct we have on the agenda later, the other three basically just need reviews, people from the IRSG to ballot. Several of them have got one yes, but we need at least two yes votes from people to progress them so please do take a look and if you think they’re OK, ballot yes. Remember they all had a detailed review by the relevant research group so it's just a sanity check from a breadth of people here that we’re mostly looking for so you don’t have to review them sort of ultra carefully, just do a sort of quick read and sanity check.
Colin: So this is a CFRG draft. I'm not sure we have anyone from CFRG here. It's waiting for the conflict review. The IANA had questions which we need answers to before it can progress, but I don't think that's holding up the IESG review, but it will need someone to to look at the IANA considerations. I think i’ve already told the CFRG chairs, but I’ll remind them.
Stephen: Just a question that will come. So this is an example of just adding more IANA stuff to a registry, and I think HPKE will likely have something similar. I don't know if we want to think at some point about whether work like that should really belong in the IRTF where there's an existing algorithm or protocol that has IANA registries and all they're doing is just kind of adding more, rows in the registry. I'm not sure what the right thing to do is but it kind of seems odd that that's an IRTF thing.
Colin: I don't know enough about the technical thing to decide. I think in some cases it makes sense for IRTF stuff to have registries, in some cases it should be owned by the IETF. I'm not quite sure which of those cases this particular thing is.
Stephen: Well I think it's I think both this one and HPKE case where the initial document it makes sense to have a registry, but whether you're maintain maintaining that registry makes sense in the IRTF or whether that should shift over to the IETF is I think a thing to think about.
Dave: Well, I see ICNRG has some experimental RFCs that have IANA registries with identified experts who are participants in the RG as the reviewers for additions to the registry. So I think we have a precedent for that.
Stephen: I'm not objecting to anything like that. I'm just the point I think in this these cases, the additions to the registry are all just kind of book-keeping protocol changes and CFRG, e.g., is already pretty busy and slow in getting things through the pipeline, so it might be that trying to encourage some of that kind of work that's mostly bookkeeping to be handled somewhere in the IETF. That might be a useful thing to think about.
Colin: I mean if this is code points for something that will be used by an IETF protocol that should probably be done in IETF. I don't understand the crypto well enough to know if that's the case. But should certainly think about the right home for the work.
Carsten: A related but different example is the kangaroo-twelve draft which defines the algorithm, essentially a hash algorithm, and now of course the registries for CMS, the named information registry and all these registries need to become active and put in numbers for this. And I'm wondering how we should organize that because there's a lot of busy work that needs to be done to make the algorithm actually useful.
Colin: That sounds like IETF work. CFRG defines the algorithm, then IETF describes how you use the algorithm in this protocol.
Carsten: IETF is big. Who actually does that?
Stephen: I think the CMS parameters is similar and HPKE is similar. There is an initial bit of work that does belong in CFRG and they do that work, they set up a registry, but then the maintaining of that might be better in an IETF context and not burdening CFRG with that administrative work.
Carsten: Yeah, so are we asking IETF to set up a structure that would enable that?
Stephen: I'm just asking the question. I don't know what the right answer is. Like you said, I mean you had another example of Kangaroo-twelve, it's a recurring kind of thing.
Colin: I would say that if we have working groups which are using algorithms defined in CFRG, then those working groups should do the work of defining the registry for how that algorithm gets integrated into their protocols presumably. I think if the registry is, these are same sets of algorithmic choices for using this crypto algorithm, that's probably something CFRG should specify. Does that make sense?
Stephen: So CFRG kind of sets the shape for the registry.
Colin: CFRG says these are the same sets of choices you can use and then the working group says use this code point to indicate you're using that crypto algorithm.
Carsten: But where does the workgroup say that? The workgroup can only say something by publishing an RFC.
Colin: I don’t see anything wrong with that.If it was that simple and then sure that would be a bit of a waste but you usually there's more to it than just use this one code point, right?
Stephen: I think the furthest I'll go is that maybe maybe this kind of deserves to be an agenda item on some future meeting where we can have the CFRG chairs and just talk about, you know, is there a way to handle this more efficiently that kind of doesn't put busy work on CFRG.
Colin: That makes sense.
Dave: Just a quick question. Isn't there in IANA the notation that some registries in order to make modifications require an RFC, others just require expert review and others say free for all, right? So I think it depends in each case what the characterization of that particular registry is, right? I mean there may be cases for just recording algorithms for TLS to use that is expert review and not requiring an RFC.
Colin: Yeah, I think they usually require a document, it's not always an RFC, but I'd have to check.
Carsten: I think we have all variants here. There are some RFC required. There is some standards action, there are some specifications required and so on. So RFC 8126 has six or seven alternatives and we have registries in all of those policies.
Stephen: I think IRTF produced registries tend to be specification required because they can't be standard. I think the IANA process is very straightforward. I think the only real question is, you know, where do we do the busy work? Is it in the IRTF or in the IETF if you can figure a way of doing it in the IETF that makes sense.
Colin: I will send a note to the CFRG chairs suggesting they might want to think about this.
Colin: Both of these I think are under control. Jerome reviewed the first one. Mirja reviewed the second one that they both need revised drafts, but I think we know what needs changing and the authors seem on top of it for both of them, so I think we'll get revisions pretty soon for both of those.
See draft-perkins-irtf-code-of-conduct + IRSG list discussion
Colin: We've been discussing the code of conduct draft for a while. I submitted an updated draft on Friday which tried to address all the comments and there has been a bit more discussion over the last couple of days.
I think most of the comments were straightforward. Laurent had comments that were mostly editorial. I think I've either addressed all of them or or explained why I think they're already addressed in the latest version, but if there are things which are still unclear, then I'm happy to consider how to change the draft. I just need specific suggestions for what is unclear.
Laurent: Thanks for replying to the comments. These were mostly editorial and matter of taste so I'm all good with the reply.
Colin: Okay, the main issue I think was about the generative AI and the use of generative AI, which both Mirja and Jana picked up on in their reviews. We had some discussion over the last few days. I sent some text to the mailing list last night as my latest suggestion for how to resolve that. I see Jana is here, I don't think Mirja is. I don't know if this addressed the concerns or if we still need to iterate this.
Jana: I read your text, Colin and I think that's good. I like the text that you have now in the email thread, and I would definitely prefer that we replace the existing one of that. I think it sets the right balance.
Colin: I think I would prefer to include some text rather than just point at the ACM policy if we can. In part because I think the ACM policy is just not particularly well written, but also they may change it in unpredictable ways. So if people are happy with the latest text? I see Stephen says ok. Carsten, Dave, you also had comments, are you OK with this?
Carsten: I generally have a preference for referring to complex text instead of extracting some and missing the rest, but the text that you sent works for me. I mean it's definitely agreeable. And I brought up the Wikipedia thing just to make sure that we are not somehow going into the weeds about needing to identify where we get our inspiration from. So that's not really well defined thing at the moment for other sources, so we shouldn't try to define it for AI tools.
Colin: The comment that this is something that's likely to change over time I think is certainly true, and yes, it may well be that this turns that Jana has right everyone just decided is not worth acknowledging in a few years. We'll see how it goes. I think for now I'd prefer to over acknowledge and under acknowledge it's easier to acknowledge too much and then relax the policy later.
Carsten: The question is whether that sentiment goes into the policy or is something that the policy recommends to other people exercising it?
Colin: I think currently it recommends that people err on the side of acknowledging and we can revise the RFC in a couple of years if it becomes a problem. I will in that case submit a revised draft with that text, and Jana, if you're happy with that, if you can change your ballot position once it's done.
Jana: Happy to do it.
Colin: I think hopefully that will then be approved and we can then move on and get this to the RFC editor and hopefully get it, get it done before my term finishes.
Jana: Sorry about throwing that wrench in. I thought about whether I should make it a point or not, but it does seem like a moment for us to discuss and figure out.
Colin: It’s better to discuss it now than afterwards.
Jana: Well I'm happy with the outcome.
Colin: Thank you and and you know Mirja had the same comment, so or at least a very similar comment, so it needed addressing. So I will submit a revision that has that new text on AI. I think that's the only outstanding comments so if there's anything I've missed, please let me know soon, but if not, I will submit that revision, do a final call just to make sure nothing has been missed and then ship it to the IESG for conflict review. We’ll see what they make of it.
See Google document
Colin: Most of the conflicts of interest policy is in reasonable shape. There's a few comments in there, some of them are pretty straightforward.
Colin: Alvaro had a comment on terminology about covered individuals, and noted that we need to specify disclosure and recusal procedures and that sort of thing. I agree that those things need to go in and would clarify the terminology and I think that's straightforward to do.
Colin: Most of the difficult comments seem to be about what counts as a conflict of interest and what to do about NDAs. What counts as a conflict, for example if you have a draft by an author from a particular company and the chair is also from that company, does that count as a conflict of interest or not? And does the chair have to recuse or not in that case?
Colin: The IESG has a definition to do with are they "working closely" together, where they define what "working closely" together means. I think the current text we have says if they work for the same company that's a conflict. The question is whether we need to adopt something closer to the IESG definition or whether the broader definition we have is OK.
Colin: The other point was how we handle NDAs. For example, if there is a research group chair who has a contract with a non disclosure agreement that might lead to a conflict of interest, what do we do about that given that they may not be able to disclose the conflict?
Jana: Is the IRSG required to go through rough consensus or is this a chair decision?
Colin: In terms of adopting drafts, it's a chair decision. In terms of publishing them, the IRSG needs to ballot on them at the end.
Jana: In terms of adoption in the IETF, one of the differences between the the IETF and the IRTF is that we don't adopt draft in the IETF without rough consensus. So a chair's affiliation doesn't actually matter so much. They can shepherd it, they can champion it and so on, but ultimately that consensus drives the decision. So I think it justifies having a stronger COI language for the IRTF against all chairs to recuse themselves because they can arbitrarily decide to bring in work that they like.
Colin: We don't need consensus to publish either. We can publish non consensus documents which the IETF can’t.
Jana: I think that's the argument against the comment there. I agree that we should keep the text then because I think we need that COI otherwise you basically create an incentive for people to go become IRTF chairs and they are now shipping documents through the IRTF for whatever reasons.
Colin: I mean that was my reason for putting it in because that there's fewer safeguards than in the IETF where you have a much stronger consensus process.
Carsten: There is a nice "should" in the sentence ("When a research group has to make a decision to adopt an internet-draft or approve it for publication, a research group chair that is conflicted with the authors or their employer should recuse themselves and allow a non-conflicted co-chair to make the decision"). I think that that's pretty much the leeway we need. Don't make this a mechanical rule but do the right thing.
Colin: I am hearing that people are ok with the current text for that particular issue. I guess the other main topic is what to do about NDAs. Carsten, I think you brought that up. Do you want to say anything about this?
Carsten: I just wanted to point out that we shouldn't adopt requirements on Chairs to to completely give up any, any privacy here and the need to disclose something should be limited to the cases where we actually need it, and then it should be limited to the chair recusing without necessarily explaining why the chair is recusing themselves.
Colin: There's there's possibly several different ways we could go. The way we have typically done this so far is that we don't require people to disclose anything about cases where they've got NDAs because of course we it's difficult to do that and we just trust them to recuse themselves in inappropriate circumstance.
Colin: The opposite extreme might be to say if you have a conflict of interest and an NDA that prohibits you from disclosing that, then you can't serve in particular role. This is perhaps the most open way in that we require people to disclose all the conflicts and if they're not willing to disclose the conflicts then they can't serve, which protects the organization but possibly excludes some people. And I guess the other way is we trust the chance to do the right thing and risk accusations of bias if it turns out that they have conflicts that they're not disclosing.
Jana: I prefer not to chase ghosts down with policy. If you have a concrete case where there is such a thing, then we can figure out how to address it. But in the meantime, I think in general, in the IRTF we've leaned more towards giving leaway and trust the chairs to do the right thing. It has worked. So unless we believe that there's a real concern here, I don't see a reason to add more guardrails because it can make things more complicated in that particular sense, in my opinion.
Colin: The question is how much you think there's a risk here.
Jana: I am saying that we do trust the IRTF of chairs to do the right thing here. I think it puts the onus of choosing the chairs reasonably. I think that's worked well unless we think there's a problem with that happening. I'm arguing that just leaving it where we allow the chairs to recuse themselves, and there are processes where there can be appeals against work that's being brought into a particular group, and so on. It seems to me that adding an explicit NDA or disclosure just makes it potentially harder for us to enforce and those requirements are really not enforceable.
Colin: Sure, that's fine. I don't have any specific cases I'm reacting against here. Do we want to say anything about that or is the existing text clear enough?
Jana: That's what I was trying to say is that I think the existing text is good. Let's not add more and then confuse the whole matter.
Colin: Okay, anyone else have comments on that? I'm hearing that people are basically happy with the current text possibly with the addition of a note about disclosure and recusal procedure and clarifying covered persons. So I will update to try and address that and hopefully we can then move forward.
See charter sent to IRSG email list on 22 Nov 2024
Colin: I circulated a draft charter, and there was a side meeting in Dublin, and discussion on the mailing list. At this point, I think we are at the point of diminishing returns on the charter. To my mind it is good enough and it's an important topic so I'm leaning towards sending this to the IAB for approval as a proposed group, but if people have comments or objections or concerns about that, now would be a good time to raise them.
Dave: I think it's fine to move forward. There were a couple of messages in the last couple of days that I haven't had a chance to really digest, that maybe somewhat me worried that part of the community that's going to participate believes that sustainability touches absolutely everything, but I don't think there's anything we could do to the charter to scope things any better. I think we just have to run the experiment and see if it starts getting out of control.
Colin: I think I probably agree, and this is one of the reasons we have several co-chairs lined up for that group if it gets charted. I tend to agree that the charter isn't the thing which is going constrain the scope. It's good chairing.
Dirk: There were comments that some of the the wording sounds a bit vague, but I'm not sure it will make a difference. For example, resiliency is a bit unclear what it has to do with sustainability.
Ignacio: I have a similar concern, of course, sustainability is a trade off with absolutely everything else. You could push to have a bit more of clarification to make sure that it's from the perspective of sustainability rather than the other way around but in practice it doesn't really matter. It depends on what the chairs decide to do.
Colin: I think in practice the charters set a direction and none of the IRTF charters are really good for constraining what groups do, that's more the way IETF charters are written. I guess set them going and review them in a year, which happens anyway as part of the process, and see where the group had gone and see if they need more focuss.
Dirk: There's one thing I think I mentioned that in Dublin is that, so for a new group, new participants who want to join, they often look at the charter in order to get some orientation on what they should possibly do. And, in that sense it could be beneficial to prioritize or list some of the say initial work items or expectations of what could be good contributions. Currently it's just fairly broad and it really depends on the chairs steering it really really well. I'm not excluding but if they want to go listing a few concrete things that they want to focus on in the beginning.
Colin: That's something we've gone back and forth on a couple of times. I'm wondering if maybe we should have the core charter text without and then ask them to just write a couple of milestones in possibly undated milestones to suggest where they're going over the first year?
Jana: This is broad, and sustainability network protocols is fashionable to think about and talk about, but ultimately there's a real question of what the value of the work is in the kind of scheme of things. Given that the scope is large and the outcomes are nebulous, I think it's gonna be really important to have chairs that can meaningfully direct conversation, Otherwise it becomes a catch all for everything and anything.
Jana: Having a research group like this would, in my mind, require us to have good, clear minded and strong chairs who can also talk about, hey, there's not much going on here. Maybe we should shut this down. This goes to Dave's point, which is that every organization in my opinion has a reason to sustain itself and that often becomes the logic. So if there was a way in which we could frame the depth of the RG, that would be useful. Though sustainability is a never ending topic and it could become one of those, one of those working one of those research groups that just keeps going on and on with no particular goals or outcomes.
Colin: That makes sense.
Dirk: This is a topic where it's probably not a problem to invite many presentations every meeting, but the question is a little bit, what is the criteria for progress and that's why I thought it may be good to have some first more concrete goals.
Brian: We have the E-Impact list, which is the IAB side of things, and we have the GREEN working group which is doing a much more focused sort of set of things in this space that are actually close to standardization. And then now there's the RG. I'm thinking that the RG ends up kind of replacing the IAB activity. It's not clear to me from the charter that that's 100% the intent. But, I think that's what's gonna happen, right? So like I'm kind of comfortable with not having an exit criterion on this particular one.
Colin: What I think I'm hearing is questions we should be asking in a year's time when we come to decide whether to turn this into a full group, to see if it's making concrete progress or if this is just gonna spin its wheels, in which case we should maybe be rethinking how to structure it and if it continues.
See https://github.com/ekline/spacerg/
Colin: Space RG is at a much earlier stage. I did talk to the proponents in Dublin and that they're definitely interested in forming a research group and their goal is to try and form a research group that complements what's going on in the DEEPSPACE group in the IETF.
Colin: Of course the issue is that the DEEPSPACE group in the IETF doesn't seem to be particularly well focused yet, so this charter can't sensibly compliment that. It looks like they want do deep space IP, going to the moon or to Mars rather than LEO, and it's looking like they want to be quite heavily research focused, which seems sensible. I think we probably have to wait and see what happens with the DEEPSPACE BOF and whether that turns into a working group and what its charter looks like. Then revise this charter probably around March/April with the goal of getting a group running by the July meeting in Madrid.
Dave: I mean, there seemed to be a pretty divided set of opinions in the DEEPSPACE BOF as to whether the Moon constituted deep space or whether you had to include Mars. Much of the time of the meeting while I was sitting there was specifically on that issue, something I'd like to understand better from a research perspective is, are the issues around the moon strictly engineering issues? What are the actual interesting research problems when you're talking about, delays and connection characteristics with respect to the moon? Mars seems a much better target if you're looking at research.
Colin: Agreed. That's definitely one of the discussions we were having. Is this just engineering for the moon? And is it feasible to do what they want to do to Mars?
Dirk: Right, and I mean if you have a chance to talk to them, so one observation from the current charter text is that there are not many research questions mentioned and it looks a lot like documenting and investigating maybe reverse engineering. I don't see much constructive work. So that would be, I think, much more interesting for a research group if you had some, you know, DTN like agenda.
Colin: It's definitely a bit hazy what's in the current one.
Stephen: Just a question to what extent are people making claims that space agencies are kind of on board with this?
Colin: It was definitely mentioned in the side meeting, but I suspect it depends on who you talk to at the space agencies.
Lixia: What I heard from the BoF, is that some people had a connection with some people from NASA, all I know. I would just say that I shared the comments so far. I don't think it's right as a research group.
Stephen: I guess it's probably more comments for the incoming IRTF chair, but trying to figure out the claims made about space agency support is tricky and if such claims are made backing up or in support of a charter or a research group, then figuring that out will be very helpful because if you don't figure it out, then you might end up in the middle of a war between two NASA centers or something. And it's not easy to figure out.
Colin: It’s really not. I think from my point of view, the thing to do here is to walk this slowly and see how things evolve with the DEEPSPACE group in IETF and see if it then turns into a sensible focused charter that complements that or if it still remains unclear what the goals are.
How did the IETF 121 meeting go? Anything issues or hot topic to report?
Nothing to report.
Colin: First of all, diversity travel grants for Bangkok applications are open till 9 December, so thank you to everyone who volunteered to help with those. Please point people at the applications if you know anyone who would be suitable for one of those. Is everything under control there?
Jenny: We already have about two or three applicants.
Colin: The ANRP reviews for next year are ongoing. We have 69 submissions compared to 59 last year, 65 the year before, so that looks to be on track and hopefully we'll have some good papers.