Session Date/Time: 22 Jul 2026 12:00
[00:00:05] Margaret Cullen: Hopefully, that means, you know, we're very close to ending that one.
[00:00:14] Valery Smyslov: So it's time to start. So hello, everybody. This is a working group session, and check if you're in the right place. So please note note well. It's a usual note well that's IETF applies to all sessions. So please remember that all which is speaking is a contribution to IETF. And, also, please follow code of conduct and be professional, respect your opponents. So some details on the meeting. So I'm Valery Smyslov. My co chair, Margaret Cullen, is remote. And our responsible AD, we have a responsibility new responsibility since March. Chris Inacio, he's not here. Well okay. So these are links to meeting slides, Meetecho, and the chat. So first of all, we have to we have to find two volunteers, at least one volunteers to will who will take notes. Oh? I answered
[00:01:47] Jan-Frederik Rieckers: it. For the for the parts that I'm
[00:01:49] Valery Smyslov: not Okay. So please do it. So I prepared now to part with some topics that we will discuss. Just, okay, fill in. So agenda for today is a bit loose for one and a half hour session. We have quite a lot of spare time for discussion if you want. So any any agenda?
[00:02:28] Jan-Frederik Rieckers: Yes.
[00:02:33] Valery Smyslov: Just a few words. It it didn't include it into agenda because the status was not very well known before the ITF meeting, so we started to chattering in even before the IETF 119 in Brisbane, but then it get delayed due to comments from during during IESG evaluation. It was a comments block position from Roman Danyliw who thought that the chart that was initially presented somehow evaluates the IETF process because we explicitly included the statements that our next working group will review attributes proposed by by other SDOs, security standards development organizations. And so he thought that it is not necessary to be in the charter because we are still IETF. We have control over our documents and are not influenced from other SDOs. If they want, they will come to us, like, general participants. Well, so we just remove this extra sentences that he didn't like. And there was a a big delay because of the well, IESG is busy. So eventually, just before this IETF starts, Roman lifts his block. And the chart the new chartered text has passed IESG evaluation. So the next part, as far as I understand from the chartered process, the chart will be sent to the IAB for review and approval. And I talked to Chris just yesterday, and he he said that it's a matter of two or three weeks. So we believe that in the middle of August, we will have a new charter officially, unless some delay happens, which was very common in IETF. So this is the status of the our recharter. So I hope it will be done very soon. We all hope. And Chris assured me that it is very possible. It must be. So so we shall see. And, actually, once we have a new charter, we will have a bunch of documents from Cisco and, I mean, from Mark and from Sri who are waiting for our rechartering. And I think that we can immediately either issue adoption calls or just adopt them. Margaret, what do you think? Because we had a preadoption call, and adoption call is not necessary from IETF process. We can just make them immediately working group document because there was high support just just not to lose time. So we can just make them working group documents. If you remember, we had a preadoption call in autumn. It was a over time and support for them. And then we can discuss them, process with them. Just I think if you don't mind, that's okay.
[00:05:53] Margaret Cullen: I agree with you. We we already, as a working group, agreed we want to adopt them.
[00:05:57] Valery Smyslov: Yes.
[00:05:58] Margaret Cullen: It's just we need
[00:05:59] Valery Smyslov: to knows that there is support for them. Yes.
[00:06:02] Margaret Cullen: And but the, we can already discuss them. We can get them to the point where we're ready to send them to the IESG.
[00:06:09] Valery Smyslov: Yes. Yes. We're ready.
[00:06:10] Margaret Cullen: But until they're in our charter, and we have adopted them and have a working group last call. But we can get ready we could have the working group last call ten minutes after the charter Mhmm. Become official if if the working group is ready. Sure. Sure. A reason not to work on them and keep going. Right? That's
[00:06:27] Valery Smyslov: So, let's start with the presentations.
[00:06:50] Jan-Frederik Rieckers: Okay. Thank you very much. So this is just a very short update on the RADSEC standards. So what happened since our last meeting? So the last meeting, we had the dash 15 draft version. Now we have dash 17, so two versions in between. All discussed discussed positions from the ISG were addressed. Mostly clarifications and wordsmithing. We added a section about ALPN so that we are comfortable with the radius one dot one document. So now we have a section in there about sending ALPN in RFC 9525. We removed the paragraph about path MTU discovery because it was really not adding any value. We added a rationale for the discussion event timestamp versus accounting delay time in the appendix with a more detailed discussion what actually breaks and how it affects congestive collapse and all that. And we had the last discuss that was the DTLS connection ID lifted shortly before the draft deadline for this IETF. So now we have wording that explicitly mentions connection DTLS connection IDs as one option for connection tracking with the caveat of please remember that a client might open a connection and then roam outside the allowed IP address space. We have open comments. This was a comment not a discuss from Eric that we have a lot of shoulds in the document without an explanation. And according to the IESG statement on the BCP 14 language, every should in a document should also explain under which circumstances it is acceptable to ignore the should because shoulds are you must do it unless you really understand all the consequences behind it. So I've went through the document. I've seen most of the shoulds are either explained in the same section or they are just, like, I would call them strong suggestions for a robust, sensible implementation. So if you write a minimal RADSEC client, then you can safely ignore these shoulds because they only apply for big operations and all the big RADSEC implementations should really use this. But if you just want to do a very quick minimal RadSec client, you don't have to abide by all these shoulds. So now the question, of course, is should we make another round and address some of these explanations or add some of these explanations to the document before it's then finally becoming an RFC. Fabian did a review of the document and found some details that I've put in a an extra branch right now that we should also include even though the the document is almost past IESG review. So one is how to deal with invalid certificates and what the clients and the servers should do if they determine, well, the certificate from the peer is not valid. So we don't have wording in that says, if the cert isn't valid, then close the connection. So probably good to add that. And another text about how to deal with connection closure, especially if the connection is closed after the TLS handshake is completed, but no traffic is exchanged, for example, because the TLS library only allows checking the certificate parameters after the TLS connection is established and then the server notices, well, this is not trusted, so I have to immediately close. And, of course, this closure shouldn't trigger an immediate reconnect because then we have the exact same problem. And one other issue that I will look at first and then put to the mailing list is regarding the server identity, which we removed, but we still have one missing point in the document still or one thing where is it is not directly but indirectly mentioned when retransmitting packets to the same server proactively. And that is a remaining bit from removing the what is the server identity. So we'll remove that, but we have to check if this one paragraph is also included in there. So with that, well, we have these open things that that we have right now, the review from Fabian. Thanks again for that. But other than that, we have no open discusses from ISG anymore. So probably, we're just waiting for our AD to tell us what neck what's next. Yes.
[00:12:29] Valery Smyslov: Exactly. So currently, the the the draft is under your control, not under working group control. So you have to decide whether these comments, not blocking comments, should be still addressed or not, which Jan-Frederik explained.
[00:12:50] Chris Inacio: So I'll have to take a look at at what's left. I mean, if all the comments that are kinda really left are
[00:12:57] Valery Smyslov: As as said, there was still a couple of shoulds that don't have explanation when it is safe to ignore this should. And Eric complained Yes. That every shoot should have an explosion. But sometimes it is very well, for example, it depends on implementation. He understands that it's it's difficult to say, for example, you should do it. But if you have very, very small and limited implementation, you can just take have no resources. So should we be very specific on every shoot, or should we or can we least leave more or less obvious shoots without So
[00:13:38] Chris Inacio: I mean, the do as many as is reasonable.
[00:13:41] Valery Smyslov: Mhmm.
[00:13:41] Chris Inacio: And if if you look at it
[00:13:43] Jan-Frederik Rieckers: and say, this doesn't I'll leave that
[00:13:46] Chris Inacio: up to editorial control is the short version of that. Right? So if you've gotten rid of all the discusses, I will take a look and see if there's anything, you know, whatever before I advance it. Mhmm. But otherwise, no. I won't make you have a unless or whatever on every should.
[00:14:07] Valery Smyslov: So please take a look and Mhmm.
[00:14:09] Chris Inacio: When when did you last post? The
[00:14:13] Jan-Frederik Rieckers: the last update was shortly before the draft deadline, so two weeks ago. Yes. So in the deluge of all the other postings.
[00:14:21] Chris Inacio: So Yeah. I probably won't look at it till next week at earliest because I already have quite a queue.
[00:14:28] Valery Smyslov: Okay. Markus, you are in the queue. We don't hear you.
[00:14:45] Margaret Cullen: I think this is a case where the perfect is the enemy of the good. Right? No documents ever gonna be entirely perfect in every single regard. Most of the I've looked through the shoulds because of that comment. And the ones that aren't labeled are things like we must do you know, server must do both PSK and certificates. Clients must do certificates, should do PSK. Mean, that's obviously to make sure that every implementation is, interoperable. There's many of them that are very like, it's very obvious why they're that way. And there's some that are that way because this is an old, old spec that people implemented more than ten years ago. And there's many existing implementations, including ones that aren't represented in the room by by a person. I mean, we're trying to to make sure all of them are covered. But, and so some of the shoulds are there because we don't wanna invalidate, existing implementations or things like that. And writing, like, something that says, well, we don't wanna do this because this one implementation hasn't been updated is really not I mean, we hope that isn't gonna be true. Right? These are things people should do, and we hope there won't be implementations that that don't move to the highly recommended stuff. But right now, the universe exists in a particular state. And I think we did the best we could to try to make a draft that points in the right direction and doesn't invalidate existing implementations and that this was a very careful, carefully done thing over time. And going back and trying to research exactly which implementation didn't do what and why in some discussion years ago is gonna be really a hard thing.
[00:16:30] Chris Inacio: Yeah. It's not necessary. I mean, I'll take a look. I mean, the important thing, obviously, is to get rid of the discusses. And I'll take a look to but if everybody's cleared the discusses, then you're probably okay.
[00:16:43] Margaret Cullen: Right. And Fabian's comments were non like, everyone knew that if the certificate is bad, you should close the connection. I mean, these don't change anything. They just make it a little clearer
[00:16:53] Chris Inacio: Yeah.
[00:16:54] Margaret Cullen: So that you can't it can't be with no one could argue later that the specification allows them to continue the connection despite the fact that the certificate is garbage. You know?
[00:17:06] Valery Smyslov: So, Fabienne?
[00:17:07] Fabian: Yeah. I think my comments that these were all things that were in before at some point and word smithing got rid of it. They are obvious. So but it's still we should clearly state it even though the one the client side is actually specified by RFC 9525, but we still put a reference to that kind of there is what you should should do if the outcome is it's invalid just to be sure that everybody knows that's the correct way.
[00:17:39] Margaret Cullen: I'm agreeing. They're they're editorial largely in in nature or clarifications of stuff we already know. They're not they're not things that change the specification.
[00:17:50] Chris Inacio: Okay. So with my, you know, AD hat on still, this is Chris Ignacio for but, anyway, the the only question I would have then is and and and maybe Margaret, Valerie is is a little bit of you guys. I'll accept those changes, but I just want you to to tell me that they still have working group consensus. So as long as the reading of the room as the working group still has consensus on that kind of text, It's fine. If there's anything that seems bigger, then it needs to come back.
[00:18:30] Margaret Cullen: Yeah. Well, we'll make we'll make the call here in the room about whether there are any concerns about any of the recent changes, and we can make a call about that on the list. There's no desire here to do anything against working group consensus. The all these things have been commented on or sent on the list already, but we'll make an official, you know, request for any any concerns or objections.
[00:19:01] Jan-Frederik Rieckers: Yeah. I I also think the the changes that I made based on Fabian's comments are pretty straightforward.
[00:19:11] Mark: Yep. Okay. Thank you. Thank you.
[00:19:18] Margaret Cullen: So I guess we should make the call in the room. It doesn't I can't tell how many people are there from here, but there are also 20 people online right now. So I guess we should make a call amongst those people whether whether there are any concerns. I you know, I don't think we need another working group last call for some editorial changes if everyone agrees they're editorial. So you wanna do that, Valerie, since you're there?
[00:19:40] Valery Smyslov: My sense that that as as said that the changes are straightforward. We don't need we can grow plus call. Just perhaps a quick consensus call.
[00:19:49] Margaret Cullen: I agree. But just can we I mean, if anyone in the room has any concerns about the changes we just
[00:19:56] Valery Smyslov: described Yes. Yes. If if anyone who reads the draft has any concern, please speak up right now. But, otherwise, we can just check on the mailing with the list, because there are only a few people in the room currently. Okay. Alan?
[00:20:17] Alan DeKok: Okay. Let's see
[00:20:19] Valery Smyslov: I can
[00:20:19] Alan DeKok: oh, never mind. I'll leave that. This is a very quick review of the deprecating insecure practices document. Some minor notes on tunnel password, which does not have the Entropy and COA request you would expect. It basically has I think it's, like, nine bits of entropy or something or 12. It's very, very low. It's still protected by the shared secret, but it's not as good as it could be. There's been text added on rate limiting. I know in practice, there are clients that if the user tries to authenticate a thousand times a second, will send a thousand packets a second. This is arguably unfriendly and potentially even a security slash DOS issue, and clients should do something about this. Do we wanna add text on rate limiting to the document? I've added it, but it wouldn't hurt for people to review it. Other than that, the document hasn't had a whole lot of updates.
[00:21:34] Margaret Cullen: Personally, I'm not sure. While while limiting implementing rate limiting is a way to sort of enforce this. I think we probably want to say, in the cases that I've seen where and we've got clients that have been, sending us thousand 17,000 requests in a minute. Okay? They are knee jerk responding. They send something like they're trying to authenticate Bob at, you know, college comma edu instead of dot And we immediately respond with invalid realm, and they immediately respond by sending another request. There's not even a client hitting a button, not even human hitting a button. The client is responding reflexively to any, rejection by sending another request immediately. Right? That should be wrong, because there should not because there should be rate limiting, although servers can rate limit to fight against that or protect against that. We should put somewhere that you should exponentially back off retries.
[00:22:40] Alan DeKok: Well, the the the issue for that is is the system which do is doing the retry as a supplicant. We see this also in ISP environments where you have ISPs who buy connectivity from other ISPs, and now their users are buried somewhere in the network. Someone loses their account or for doesn't renew it but keeps the equipment plugged in. And that fiber box, DSL box, whatever, will immediately do another access request or another PPP login after getting a reject. So those devices should be doing it but aren't. The next step then would be to suggest that the NAS, the radius client, should see this and stop it itself because there's a lot fewer radius clients than supplicants. Similarly, the insecure practices document also suggests that access rejects should be delayed for a short period of time, which in practice also seems to help. So this this is really about a defense in-depth for these issues. We can't fix the applicant. So and just go ahead.
[00:23:49] Margaret Cullen: Well, I mean, I'd like it if we at least said that that, know, client devices, whatever, should exponentially back off. In the case that they don't, we could have you know, we we could also say that that, you know, the NASA should do rate limiting of individual devices that are not backing off high. Yeah.
[00:24:12] Mark: So so do we need need to well, I think we do need to clarify somewhere on rate limiting. As I understand it, there's nothing in a RFC 5080. There's nothing in a there's nothing anywhere that talks about exponential back off. People can look at WPAs applicant and saying, okay. That's how some open source have implemented it. But shouldn't we as an industry recognize that this is a problem and needs to be defined somewhere as a recommendation?
[00:24:38] Alan DeKok: Yeah. I looked at the eight zero two one x spec, and it says that the authenticators, which for us are are the radius clients, shouldn't send more than about five packets a second. But that doesn't seem to affect anyone in in practice. But, yeah, this this really is an issue for IEEE perhaps and maybe even also someone like the Wi Fi Alliance.
[00:25:03] Mark: Or EAP.
[00:25:06] Alan DeKok: Yeah. Yeah. Questions, are we gonna rev what was it? Thirty five eighty? Thirty no. Thirty five seventy six is the underlying RFC. I don't know we're going to rev that at this time, but it wouldn't hurt to publish another document going, by the way, here's a list of insanity we've seen. Please, God, fix it.
[00:25:27] Margaret Cullen: Yeah. I mean, I just think maybe I think we should add rate limiting, but I think we should make it clear that we're, you know, we're only at you know, we only need rate limiting because there are clients who don't do exponential back. And that it should be, like, per client rate limiting, not overall rate limiting or per per it shouldn't be per, NASS rate limiting. It should ideally be per user device rate limiting if you can
[00:25:57] Chris Inacio: if you can
[00:25:57] Alan DeKok: I I would argue we need all of that because in addition, there are other NASs that will take your 10,000 accounting packets or accounting sessions and have a ten minute timer? And once every ten minute timers, we'll send 10,000 accounting updates. That's unfriendly. So all this has to be explained. Yeah. But meeting Friday. I'll I'll I'll bring it up there too for the supplicant. Okay.
[00:26:32] Valery Smyslov: So thank you. Next.
[00:26:40] Alan DeKok: So this is the review of Radius security. Here we are. So this was split from the deprecation document because that one was getting enormous, which makes all the documents a lot easier. It's been accepted as a working group draft. They're based on reviews. There's text added on forwarding inner tunnel data. So if the RADIUS server terminates the TLS connection and forwards the inner data, there's additional security issues there that people should be aware of. I added a section on security analysis of CHAP. I could not find anything on that, likely because it's MD five and no one even bothered. But at least this should be a public statement that the use of CHAP and CHAP password is plain text equivalent at this point. Given a couple 100 gigs of data and a couple milliseconds of time, you can convert pretty much any chat password information into the underlying clear text password. Then it needs some additional reviews, minor touch ups. Ideally, this should be part of the same cluster as draft-ietf-radext-deprecating-radius just so we have all of that wrapped up of here's what Radius was like, here's draft-ietf-radext-review-radius to fix it, and here's recommendations on deprecating and secure practices and recommendations to use TLS. I think that's it for the review document. Margaret.
[00:28:29] Valery Smyslov: Nothing? Margaret, on the queue.
[00:28:33] Margaret Cullen: Sorry. The, this document and the last one, they haven't been through a working group last call yet. Right? No. So, it sounds like this one at least is ready, and that the previous one will be ready as soon as you decide what to do about the rate limiting wording.
[00:28:49] Mark: Yeah.
[00:28:51] Margaret Cullen: Yeah. So, so let's get these into working group last call, you know, after this meeting as soon as as we can.
[00:28:58] Alan DeKok: Yep. I'll issue updates in August, and then they should be ready for at least November.
[00:29:04] Margaret Cullen: Yeah. I don't mean, like, the second after this meeting. I mean, you know, you you have a couple things to do, but but as soon as you can after this meeting, do them so that we might be have them done by the time we get to all meet again in San Francisco. Yep.
[00:29:22] Valery Smyslov: Okay. Thanks. Next. It's Alan again.
[00:29:30] Alan DeKok: So this is the protocol error document. This is this has been discussed for a while. We did a initial interop in Montreal last November. I've gotten some more feedback from Fabian since then. The document does need some updates. The reality is silently discard is likely terrible. So instead having a protocol error going, I received your packet, but I don't know what the heck to do with it, is a lot better and will help with network stability. For now, we're not proposing any kind of link layer negotiation. It should be safe to send protocol error responses even if you don't know whether or not the client supports it because the client should ignore it. And then much of the document text is explaining how people get things wrong with radius in general and how to improve them with protocol error. We also plan on doing some real world testing, August. We have agreement from a bunch of people in to test this in a live environment, and I should be able to report back before San Francisco as to what that status is. Minor issues. Do we care if protocol error contains proxy state? We don't need it. But for sanity, it's probably good to keep it. We probably also want to define a number of new error messages. So the idea is that protocol error not just says, I got this packet and don't know what to do with it. It says why. And the existing values for error cause are sort of vague. Most of them actually aren't really referenced anywhere, and it's probably good to define a whole set of errors for these this this specific case. You know, cannot proxy is not I can't proxy. It's maybe I know the realm, but all upstream connections are down versus you sent me something that I don't know how to proxy. Those are two different error cases, and they're not distinguished in the current specs. And that's it for this one. Fabienne.
[00:32:07] Valery Smyslov: Fabienne?
[00:32:08] Fabian: Yeah. So as I said, I was testing a lot of corner cases during the hackathon, discovered a few edge cases, which probably warrants different error messages. There is one particular statement that the the draft should define which errors are permanent and which are recoverable. So far, all defined errors are permanent errors and really telling the client, stop it. It's never going to happen. But I also found a few cases where kind of, okay, if you try again in a few seconds, it might work. Yeah. There's also one statement in the RADIUS over (D)TLS-bis draft about when silently drop is acceptable, which is if the proxy or server is out of resources, which just we have to keep in mind. We explicitly state there that this is allowed to have no response and probably is because if you're out of resources to actually handle the request, you might as well be out of resources to even send a protocol error. So
[00:33:24] Alan DeKok: Yeah. And there there's other tweaks. Like, if you if you return an error saying, I can't proxy it because I don't know this realm, it might be useful to include the realm in the answer because, arguably, the username may or may not contain a realm, but there's all kinds of odd corner cases there, which we might be safer to just ignore. COA? Mark?
[00:33:56] Mark: Yeah. I think, obviously, we're gonna look at COA. I mean, at least COA has has got a NAC request not routable. Yeah. And so just trying to tie things together. But but also, obviously, from a COA perspective, I guess, we we still permit no response to COA. Yeah. Yeah. Yeah. The request not routable seems applicable in both cases.
[00:34:21] Alan DeKok: The question is why is it not routable? Is it a transient uplink down, or I have no idea what to do with realmexample.com? The COA also COA documents thirty five seventy six also says you send a knack in a bunch of other situations. There is some text in the protocol error document saying you may wanna send a protocol error response instead because the COA NAC is also overloaded then with, I received the packet but could not do the operation because there's no matching user session versus, hey, I can't route it. So the question is what to do where. And the document suggests that a lot of that can be made configurable because it really depends on your network and and what your systems implement and what they can handle. Yeah.
[00:35:19] Valery Smyslov: K. So, Margaret?
[00:35:21] Margaret Cullen: I first off, I strongly agree with the we need transient, nontransient errors. And we need to be able to tell them apart not by knowing that error, but there needs to be some sort of indicator. Even if we don't know this particular error code is a transient or, nontransient. But if we review the errors and we say, well, they're they're all, nontransient. I mean, that isn't true. Like, not routable can be, I don't have that realm configured at all, and therefore we'll never be able to route to it without some sort of reconfiguration or all of its, I of its home servers are dead. Okay? And those are two very different cases because when all of its home servers are dead, there could be a power outage. It could last thirty seconds. Okay? There's no it's not, we we it would be very important in that case to say this is a transient error or nontransient error. And you might even want a separate error for the realm that you're trying to route to is malformed, not it's it doesn't happen to be valid. It needs a reconfiguration. That's a different kind of transient, a much longer lived kind of transient. And then it's malformed like it has a comma, and it is a permanent Yeah. Error.
[00:36:41] Alan DeKok: Yeah. The original error cause definition has number ranges for proxy errors, number ranges for permanent errors, number ranges for temporary errors. But, yeah, those all need double checking.
[00:36:54] Margaret Cullen: And the other one about there might still be some cases where we need to to just drop stuff. There may be cases where we want to just drop stuff. We don't want, for instance, in those former storms we talked about with rate limiting to respond 17,000 times. Okay? The, we want and we might talk here about rate limiting the number of responses we send with protocol errors in them to what our retries of essentially the same request. I don't know how to define that, but we certainly don't wanna get to a point where we're it's very easy to create a distributed DOS attack because we will storm back, responses to storms of complete garbage requests that didn't require any crypto to create or tiny crypto to create and and basically making it easy to do a denial of service attack where we do half the work. Yeah. So
[00:37:56] Valery Smyslov: Okay. Alexandra, I will pick up on the queue.
[00:38:00] Alexander: Hi. Picking up from Margaret's. I about is this a permanent error or transient and or if all that's needed to unlock this is maybe a configuration change. Some ways to solve that might be I mean, like, the other document, there's another document going around about, rate limiting, you know, pushing the reject down towards the NAS so that you've got a TTL there kind of thing to help expire. Hey. Just come back after a while. Another way, a lot of these servers do have a concept of configuration version, and it might be meaningless to the other end what the actual version is. But you could send it like, hey. When this value changes but then somehow it still needs to see it. But, you know, we kinda got a chicken and the egg problem. When are gonna send protocol error again? But that that that's just the thoughts on how to break out on
[00:38:53] Valery Smyslov: that one. Yeah.
[00:38:57] Alan DeKok: Fabienne?
[00:38:57] Fabian: Yeah. Regarding permanent or not permanent, my thought was in in the direction of client. If you send this request again with the exact same content and I didn't change the config, would it fail again in the same way? Yeah. If yes, then it's a permanent error. But if kind of I've just failed because I have a memory allocation error that the next second could be okay, or now the upstreams are actually live, so I can pass it on, then it's a temporary error.
[00:39:36] Alan DeKok: Yeah. Yeah. I I seem to recall also there's a configuration token attribute. We'll have to double check. For Alex's comment, it wouldn't hurt to send some opaque token saying this is for server configuration x. What does that mean? Who knows? But if you see it change, then something changed. And maybe at that point, you might be able to try the realm again. That could be useful mainly for the administrators to see that, hey. I'm being rejected because the upstream hasn't changed its configuration. Margaret.
[00:40:15] Margaret Cullen: One possibility might be to include that configuration blob, that opaque number or whatever it is, in a status server so that you could do, like, a status server note, you know, every thirty seconds if you've, you know, are waiting to send something and find out the configuration changed and then send the set of stuff you are holding. If the if it you know, if you're holding stuff, I'm not really arguing you should hold stuff, but it would be a way of making that opaque checkable.
[00:40:44] Alan DeKok: Yep. Yeah. That's a good idea. I'll update the doc. Okay?
[00:40:51] Valery Smyslov: Thanks. So the next one is also Alan, but not Almost done. Not not not explicitly related to reduce, but somehow.
[00:41:09] Alan DeKok: Yeah. The this one is really a FYI. So OPSAWG has noticed that there are a lot of management protocols, telemetry that don't have transport security. Tons of stuff goes over UDP. The thought here is to have them give them a shared security profile. So step one, put them all over quick, but we don't necessarily need to define quick transport individually for each of these protocols. And because they're all telemetry, they're all shared under the same administrator, you might just wanna have the same TLS configuration for all of them. And because not all of them send masses of traffic, it wouldn't hurt to just push them all down the same quick connection. So rather than having a certificate per protocol, you have a telemetry certificate among other things. So the idea is you have one quick connection that carries everything. There is a two byte telemetry header that once the other end gets it, it can decode that data into radius IP fix whatever and send it to the correct destination. There's no requirement to send multiple kinds of telemetry over the same TLS connection, but it is useful. And then depending on what you want out of it, datagram, stream, whatever. So a bunch of advantages, sharing the same administration overhead, sharing the same certificate. The idea for this also would be to get rid of MD five and just use the RADIUS/TLS-bis profile, which is a lot easier. And the initial profile in this document is radius accounting, not authentication. That is perhaps TBD. Chris.
[00:43:28] Jan-Frederik Rieckers: Alright. So since I don't pay enough attention to, let's
[00:43:30] Chris Inacio: say, OPSAWG, this was in OPSAWG. Because I will say in IP fix, there's an SCTP profile. In the SCTP profile, you would the streams and you'd send the templates over one stream and you'd send the data over a different stream. And so you'd have a different template management than you would on your data stream. And if you were porting it to quick with, you know, kind of the multiple streams or whatever, you'd wanna do that Okay. As opposed to using the timers that are in IP fix for straight UDP. So, obviously, probably, this isn't the right venue for this conversation, but I I don't know who's who's leading that up. Benoit. Of course. Okay. Thanks.
[00:44:13] Alan DeKok: Yeah. Yeah. I'll talk to Benoit about that.
[00:44:17] Chris Inacio: He was a primary instigator of IP fix in the first place. He knows.
[00:44:21] Valery Smyslov: Yeah.
[00:44:24] Mark: Next, Mark. Yeah. Isn't this a deprecating problem? How can we move it on that we're having DTLS and TLS?
[00:44:35] Alan DeKok: Yes. For radius, there hasn't yet been discussion of radius over quick. The thought here from the ops area is if there's five or six telemetry protocols that all do the same thing, throw them under the same header. So there would need to be a radius over quick document defined separately from this.
[00:44:59] Mark: Right. And I I think that we've seen a submission last time about radius
[00:45:03] Alan DeKok: over quick. There isn't a huge amount of interest in that. We'll see what happens. I I think it's probably worth defining this for radio or wrapping all this up with radius even if there isn't a radius over quick document or leaving the provisions open. And if and when we do a radius over quick go, by the way, here's the profile for the telemetry.
[00:45:34] Mark: Okay. Yeah. So I I guess I guess, you know, if we're all transitioning and and and pushing everyone to transition to to TLS, DTLS, then, you know, it would seem that we should focus on that transition. Yeah. Yeah. No. I I agree.
[00:45:46] Alan DeKok: I mean, there's there's no immediate plans to implement quick for radius or even even work on a document for it. Who's next in
[00:45:56] Valery Smyslov: the queue? Margaret.
[00:45:58] Margaret Cullen: Margaret. So, yeah, I I guess my concern would be kind of confusion and exactly how, you would I don't think we wanna be in a situation where there's two different ways to run radius accounting over TLS, and you need to decide which one you're doing and there could be incompatibility between one type of equipment only does this one and one type of equipment only does RADSEC. And so I think without some sort of clear explanation about when you use which one or how you transition one to the other, like this could this could cause more confusion than value would be my concern. And so I, you know, I guess I'd like and and I would trust you if you said, you know, well, we're gonna this these reasons we wanna use this in these situations and the other one and the other situations or something. But but I I only really kinda glanced at this document, but I didn't see anything along those lines. And so No.
[00:47:06] Alan DeKok: The the the document's really an initial thought right now. The main reason to do this is administrator simplicity. Right? If you're doing multiple protocols that all sort of do related things, it wouldn't hurt to have them share administrator security profiles. Right? But, yeah, there's a lot more work to do before we actually recommend it. Fabian?
[00:47:35] Valery Smyslov: Yeah.
[00:47:35] Fabian: Thanks. Sadly, I I missed the OPSAWG session, so couldn't be there to voice my opinion. I have many issues with this document. Probably, the only thing I would agree is that such a device could have one certificate which is used for all traffic, which is fine. Stating that all those telemetry are the same and have the same properties, I strongly disagree. We had discussions how to put radios over quick. If we would do it, what properties would we need? And I suspect they would be would have to be defined for each separate protocol. Then just having one working group define, Okay, we are taking all these protocols from a number of different groups and putting it all on our transport is kind of
[00:48:43] Alan DeKok: Yeah.
[00:48:43] Fabian: It would be fine for a layer two or layer three protocol, but for layer four Yeah. So my issues with that.
[00:48:51] Alan DeKok: So so the document does not define quick issues for radius. That's explicitly somewhere else. But if you do want the intent of the document is that if you do want to have shared management slash administrator overhead, here's how to do it. And, yeah, exactly where to draw that line can be complicated.
[00:49:19] Fabian: I mean, just the management part of the security, yes, please. Let me define one certificate with maybe all the properties around it for a device and then all those protocols could use it. As far I'm aware, many of the mentioned telemetry protocols already have, at least in the draft state, a secure version of it. They might not have deprecated the old ones, which we are also just in the process of doing, but there are secure methods for almost all of them. Also, kind of citing, well, there is all those proposals who would want to do X over QUIC, but none of them have been accepted by any working group as a working group document. They are all just individual things which we don't even know whether people agree with them or not. Yep. Yep. And
[00:50:17] Alan DeKok: well This is a little future look. But yeah.
[00:50:20] Fabian: I One final thing, I thought, as well, we're talking about radios, but only radios accounting is sort of telemetry. Yeah. Radius authentication definitely isn't, so it shouldn't be in there.
[00:50:35] Mark: Yeah. Okay.
[00:50:37] Alan DeKok: Next. Margaret.
[00:50:39] Margaret Cullen: I'm speaking only as myself as an individual. I agree the working group doesn't have any consensus to do Radius over quick. There was a presentation. There was not consensus to do anything with it. But I am intellectually at least interested in Radius over QUIC. And if there were people who wanna use it, which is the the the missing piece, right, and very important missing piece, I would be happy with the idea that we would define it. And we did have meetings with the quick people and talk about what would be involved. But I think that should come first before we start talking about how to put it on a connection with other things that also run over quick because we don't run over quick. Okay? And so I think before we can start talking about putting our quick stuff on a connection with other stuff, we need to have this is how we run over quick. And there was zero interest from anybody who said they might implement it.
[00:51:34] Valery Smyslov: Yep.
[00:51:36] Mark: Alexander is next.
[00:51:39] Margaret Cullen: Hi. This
[00:51:40] Alexander: I'm I'm I'm okay with this because it sounds like it's more I've got something that's a NAS. I could imagine like an ISP in the old olden days. You have an L2TP concentrator that also could do NetFlow. And it's like, I've got several different signals. I've got my accounting radius accounting flows. I've got my NetFlow signals. I've got all these other things, SNMP traps. And it sounds like it's to send it all to maybe another single security appliance that just eats everything. And I can see that the advantage there is more you want to you don't wanna set up 20 different ports with 20 different protocols to receive different kinds of flows from different devices. You just have, like, this is my accounting protocol and stuff slipped in there. Whether or not it it I I don't see it so much as this is just a way to get your SSL jacket your TLS jacket around it and help. So is that that kind of what the draft was aiming for? Because I didn't get a I didn't read the draft. Is that
[00:52:40] Alan DeKok: The the the draft yeah. The draft is is very, very simple. It's presuming that each of these things has quick transport defined. Here's a way to share common administrator security overhead.
[00:52:51] Alexander: With the idea that, like, maybe an appliances has five of these protocols and wants to send it to a single destination maybe? Or yeah. Yeah. Okay. Sounds great. I mean, thumbs up.
[00:53:03] Valery Smyslov: Okay. Yeah.
[00:53:05] Fabian: To Alex's comment, in my personal operational experience with network devices, mainly routers, the idea that all telemetry goes to a single place simply isn't true. Every protocol has its own receiver instance which runs completely different protocols.
[00:53:27] Alan DeKok: Yeah. Okay.
[00:53:30] Valery Smyslov: So normal people in the queue, the things. Periodic update.
[00:53:45] Alan DeKok: One one final thing. Yes. Not periodic update. Sorry. Typo periodic update. This is a proposal based on how some people implement things. So if you have many access points, which are not under a shared controller, the users can roam between multiple APs within one accounting interim interval time period. So if you're in a apartment complex, big box store, you run back and forth quickly between two or three APs. And depending on how people have implemented it, every time you connect to an AP, that's an accounting start. Every time you disconnect or come back, whatever, that's an accounting stop. And in practice, some of these systems end up having accounting turned off because you just have too many packets. The idea is to add a accounting status type periodic update where the APs then would just send one packet for each time period. All of the data gets aggregated for that time period, and this is a self contained start stop update packet. So within, say, a ten minute period, the user had so many gigs of upload, download and so many minutes of actual connection time. Maybe even at a counter in there about how many times they connected and disconnected. Initial investigation shows that this may end up dropping the number of accounting packets by at least two, maybe up to 10, depending on your implementation and operation. And that lowers the offered load significantly, which is very positive for a lot of people. Some additional things. So there's probably wanna include the interim interval so you know how long or what time period this packet refers to, add accounting session time. There's no draft for this. This is really do people find this useful? And if and when we finish the current working group documents or at least make progress on them, would this be a good thing for people to work on? There was some interesting support on the mailing list from people who are not traditionally involved. So that is part surprising, part positive, but all all good. I think that's it. Any questions or comments? Mark?
[00:56:41] Mark: So isn't this sort of recommended how how to build a NAS? As I understand it, so some NASs implement this when they have a single aggregated session and hide mobility and others expose that in individual accounting. Yeah.
[00:56:56] Alan DeKok: Yeah. Arguably, we have the proxy BCP document, which is split off from the big radius security document. Arguably, the proxy BCP draft could just be RADIUS BCP and add a recommendation about this behavior too.
[00:57:12] Mark: Oh, we have NAS BCP.
[00:57:16] Alan DeKok: Yeah. There's there there's there's a bunch of possibilities there.
[00:57:20] Mark: Yeah. Right. I mean, so so alter but then to aggregate, so if I've got effectively separate NAS, I guess, sessions that I I somehow need
[00:57:30] Alan DeKok: to bind those together and and maybe not using multi session ID. And so this So the issue with multi session ID is that defines the overall session for the user. Then if you have multi session ID, you can have multiple accounting streams with accounting session ID. So even if you use multi session ID, arguably according to 2866, you still could get start stop for every connection disconnection from an access point. And the question is what to do about this? What are the best practices? No one thought of this in, you know, '97, '99, but the world has changed, and it would be good to actually figure out what the best thing to do is and then write that all down.
[00:58:22] Mark: Okay. Thanks.
[00:58:24] Alan DeKok: Yeah. So some people may want to know that a user's moved from access point to access point when they've done that. Other people don't wanna know. So there is no real perfect solution here. So the idea would be to part document what is the recommended practice and part update radius to allow people to do what they want to do. It won't make sense for them. Hearing nothing else?
[00:58:53] Valery Smyslov: There's no draft yet.
[00:58:55] Alan DeKok: There's no draft.
[00:58:56] Valery Smyslov: Mark
[00:58:59] Alan DeKok: again. Yes.
[00:59:03] Mark: So so so maybe a slightly different use case, but one we're we're addressing now as we as we take EPCS and and and integrate that into systems is is does the priority service, priority tunnel access, does that trigger a separate accounting? So I think that they're gonna be different use cases where, conventionally, it was we're gonna have an accounting start, interim stop. But now we have these other fancy use cases where where we've got to think about sessions more broadly and different use cases. So, yeah, I think it could be sort of time to understand the different requirements, because it may be that your priority channel access needs to be rated differently, which then obviously drives a particular requirement. I don't know if there are other use cases where that is a requirement for, as you say, providing visibility, but maybe it will be good to start with a different set of use cases. Yeah.
[01:00:01] Valery Smyslov: So, Alan, are you going to write something, some drafts?
[01:00:05] Alan DeKok: I I I think in the short term, if I'm lucky, I will get a draft before November. Mhmm. But other than that, maybe December because I'd like to not confuse things by adding more documents and instead try to get the deprecation and the review document out.
[01:00:27] Valery Smyslov: Yeah.
[01:00:27] Alan DeKok: Sure. Maybe even get some progress on protocol error.
[01:00:31] Valery Smyslov: Sure.
[01:00:31] Alan DeKok: And then after that, take a look at at this one.
[01:00:36] Valery Smyslov: Because if if you can drop it, it would be easier to Yeah. To discuss.
[01:00:40] Alan DeKok: Yeah. Also, the proxy BCP document is extremely thin right now. That needs to be updated. And then maybe we want a NAS BCP, proxy BCP, and server BCP. I don't know. But there's a lot of text there. The main issue I've been having with all of those recommendations is getting information from people as to what they do. Right? Not everyone is willing to share that information or not everyone is willing to join the lists and talk about it. Not everyone has time to do that. So unless there's a lot of content, some of those documents end up being, well, I end up writing whatever I I remember from with the last couple years of practice and hoping for the best. So the the priority for any kind of BCP document is a little up in the air until we start seeing some real need for it and demand for it from lot of operators and vendors.
[01:01:44] Valery Smyslov: Okay. Thank you. So next presentations. Mark, please.
[01:02:03] Mark: Yeah. So real quick on connect info updates. So I think this is the fifth time we've went to connect info. In Shenzhen, we did a reorganization taking on board the the feedback from the email call for adoption where we removed all attributes which weren't connection related, which was the email feedback. Slight updates, small updates since then. We've added a sample period to the exponential weight algorithm and also reduced the global operating class because it does relate to the connection, which then means that if your Wi-Fi 7 on MLO, you can then provide the global operating class of each of your connections. So the AAA is is aware that you're operating on which frequency bands, etcetera. They're just calling out further demonstrations of of use cases. We've now since integrated now ConnectInfo draft into OpenRoaming. And, anecdotally, we hear that providers of OpenRoaming are now requiring this ConnectInfo syntax in in their equipment. So we should see some increasing adoption of ConnectInfo. Just as it relates to that, I see Joey online, so call out to Helium. So Helium have deployed, it across their portfolio. So this is 17,000 access points, three three hundred fifty thousand daily sessions. You can see there the the RSSI from ConnectInfo overlaid on their hotspot directory. And one of the use cases is to use, ConnectInfo in authorization. And if you can squint, you can see that that's an RSSI based authorization where there's a threshold of of minus 70 dBm. And so if the RSSI is above minus 70 dBm, then you will accept. And if not, you reject. So we're seeing positive adoption of the syntax. And I guess just finally, as as we started the discussion today, looking forward to, obviously, the rechartering to complete, and then, obviously, the the call for adoption once we've come completed that rechartering and, obviously, taking on board any other feedback on the latest draft. That's all I'm connecting for.
[01:04:29] Valery Smyslov: So any comments? So as we discussed with Margaret, once the new charter is will be approved, we will be officially rechartered. We will just make the draft that we can do.
[01:04:45] Chris Inacio: Yeah. So, Chris Inacio, the so the charter's out of the IESG. The secretariat should be pushing it out to external review. So two weeks should Yes.
[01:04:54] Valery Smyslov: I I just told the working group about this. Yeah. Yeah.
[01:04:59] Jan-Frederik Rieckers: So it
[01:05:00] Valery Smyslov: should be Two weeks should be.
[01:05:02] Chris Inacio: Okay. It should be the new charter.
[01:05:04] Valery Smyslov: Yes. Thank you.
[01:05:06] Margaret Cullen: The important point here is that we already made the call for working group adoption of this draft pending the new charter, and people were interested. So I don't think we'll have to wait through a working group option call. We will you know, you'll have to publish new version after the charter comes out that's working document, and there will probably be some more visibility to people then. And we I I said, you know, we could send it anywhere ten minutes after, But, I mean, we won't because we want there to be visibility to people. So there will be you know, we will publish it as a working group document after the recharter, and presumably, there might be some more discussion of it then because there'll be a little more visibility of it. But I think we're you know, the lack of response here is not lack of interest. It's just that it's more or less done. I mean, it's just a matter now of process to go through the steps and make sure there's plenty of visibility and then get it out.
[01:06:06] Mark: Yeah, Margaret. I'm happy happy to work with you and Valerie in terms of what's required the adaptations as it goes into work group adopted. So, yep, let's, do that in the next few weeks. Okay. This is a new draft, draft zero zero, called WBA vendor specific attributes for Wi Fi network quality metric reporting. And so the background here, as as we've just heard from the the call for working group adoption on the email from last September, I think it was September, October, is we we got, advised to remove those key value pairs which weren't related to the connection from connect info, and that's what we see the syntax today. But there are use cases where that that information that was removed, those key value pairs, is still of interest to the community. And therefore, given that the advice is not to overburden ConnectInfo with this information, we've defined a new draft, currently using WBA's VSA fourteen one two two, that defines these additional non connection related information for either instrumentation, primarily instrumentation, but a little bit of configuration. So the examples are the the one round trip time, the Wi Fi channel utilization, the Wi Fi noise level, the number of active Wi Fi stations, and then two configuration parameters. One is the minimum RSSI. So what is your minimum threshold that you will accept, associations? And then what are your supported Wi Fi global operating classes? So so is this access point supporting 2.4, five, six, and how are those configured? So so that is the background about why we we generated this draft. Now our complication as it relates to radius is the complex attribute challenge. So if you think we have an access point, and we have an access point with a number of different operating bands. And we may have multiple different radios operating in one of those operating bands. So in this example, Wi Fi access point has got four individual radios. And we're defining a set of attributes. So here, see channel utilization, noise, station count, which are then reported per per radio. We have a set of metrics so you can report the minimum, maximum, median, and average of each one of those. And, also, we have the optional algorithm about how that that parameter was was calculated. And so the issue is is how do we encode this in a set of radius attributes? And, obviously, if we look at sixty one fifty eight, it it advises against using complex data types, but it does permit or at least indicate where that may be permissible. So sixty one fifty eight states that complex data types may be employed where they reduce complexity and where basic data types would necessitate cumbersome grouping mechanisms. And so our analysis is this is a cumbersome grouping mechanism where we're trying to group an algorithm, a metric, an attribute, a radio, a frequency band into a single attribute, as it were, related to a radio. So with that in mind and sixty one fifty eight saying that that we can use complex in certain situations, this draft defines the use of complex data types using fourteen one two two vendor space. So as an example here, we've got the one RTT, which isn't specifically related to a radio. So we we don't have radio called out there. But then we when we're looking at the noise attribute, the station attribute, we have the the band and the radio defined in the complex data type. So we would welcome feedback on the draft. Obviously, this is the first time we've presented. And then just in terms of moving forward, in particular because this is informational and WBA vendor space, then advice from this group as to whether we move forward with the independent submissions editor route and obviously adapt the draft accordingly. So first time we presented here, but appreciating thoughts and feedback. Thank you.
[01:10:59] Margaret Cullen: I have some thoughts. They're just personal thoughts. I haven't really thought about this in a way that I would have a well formed chair thought on this yet. So let's take this as my personal comment. Right? Many organizations, including Painless Security, my tiny little company, have vendor defined attributes. Right? Because we have a pen number and can therefore define our own attributes, we do. They're published in some dictionaries or they can be, you know, published other ways. I'm I'm not a 100% sure, like, if there's a history of independently published RFCs that contain the definition of people's attributes. Does anyone know if that's a commonly done thing?
[01:11:49] Mark: I I guess not. I guess the the example would
[01:11:51] Valery Smyslov: be the
[01:11:51] Mark: Microsoft VSAs for the keying material. But yeah.
[01:11:58] Alan DeKok: There's also, I think, forty six seventy nine DSL ADSL vendor forum attributes. So it's not common, but it's not unusual.
[01:12:11] Margaret Cullen: Yeah. It's just a little, like, weird. I mean, I you know, I guess anybody can publish something through the independent, editor if the independent editor agrees it's useful and agrees to publish it. Right? That's not but I just wonder you know, I don't think there's any problem at all with you coming and asking for a review of stuff, certainly not at all. But I wonder what the right, like, publication, like, vector is for stuff like this and whether what way we want it to go in the future. And I as I said, I don't have well informed thoughts about it. It's good to know there are some previous ones. And, if we're being asked by the ISE to, say whether or not we think this makes sense for ISE publication, Maybe we would want to and which I don't think has quite happened yet. Maybe we wanna have an idea of which ones what, like, what are the characteristics of of things that should be published as RFCs and things that shouldn't? Because I think pretty much everyone agrees that painless securities vendor options or a lot of the ones done by Aruba or others shouldn't really be published as RFCs. They're vendor specific. Right? And what makes something vendor specific, but I guess widely used enough to make sense to to RFC publication? I have no real real feel for that. So I think that's something we probably wanna think about with regard to do these attributes, but also possibly other attributes that are brought forward by other people. You know?
[01:13:55] Mark: Margaret, thanks for that. Yeah. And I agree that maybe this is a discussion with the independent submissions editor because I'm sure that'll be one of the the their first questions is is why is this being proposed as as a a an RFC publication rather than, as you say, a WBA publishing this in in with with their particular route to to public public publish their their particular sets of VSAs because this isn't the only WBA VSA. So, yeah, I think that's that's a good feedback. Thank you.
[01:14:34] Margaret Cullen: Yeah. I just wanna make it clear that I don't object to us reviewing these things. I I'm just talking right now about the public how they should be published, not not whether or not it's appropriate to bring them to our review. I think that's excellent to to bring things for us to review.
[01:14:53] Jan-Frederik Rieckers: Ben?
[01:14:55] Fabian: Yeah. My comment or other question is very much technical. So you're specifying data about the access point. I guess that's supposed to be transmitted in an accounting packet.
[01:15:11] Alan DeKok: Or In
[01:15:11] Valery Smyslov: an access
[01:15:12] Fabian: transfer that info and to whom? In an access request.
[01:15:18] Mark: Alright. Or it could be an accounting request. Yeah. So so both access request and accounting request.
[01:15:23] Fabian: So would you basically copy the metadata or kind of telemetry data of the access point in each access request.
[01:15:33] Valery Smyslov: Correct.
[01:15:33] Jan-Frederik Rieckers: Okay.
[01:15:38] Valery Smyslov: So, Joey? Joey? Oh, sorry.
[01:15:46] Joey Patton: Hi. This is Joey Patton from Helium.
[01:15:54] Valery Smyslov: We
[01:15:56] Joey Patton: strongly support a standard way to communicate this to telemetry in radius messages. We're working with large operators internationally who are interested in getting real time or quasi real time updates on the, proposed telemetry metrics that are in this document. The question I he have is if there are concerns about the proposed use of the WBA-Quality-Metrics space, is are there an alternative AVP or a way to propose a new AVP to having to be purely a WBA published vendor specific attribute, to put it bluntly, carries less weight than having an approved ETF RFC if you're asking a equipment OEMs to implement a feature. Having an RFC, just gives people a warm fuzzy that it's community reviewed. It's a standard approach. It isn't a right, very one off ask.
[01:18:41] Mark: Thanks, Joey. I I guess in terms of moving forward then, if it wasn't vendor space, so so would would Radext accommodate a comp a new complex data type given sixty one fifty eight or or yeah. So advice on how to move forward on vendor space versus non vendor space.
[01:19:15] Alan DeKok: Yeah. This is Alan. I mean, if they're complicated and cannot be reasonably put into some kind of TLV format, Sure. Right? Do do whatever makes sense and is easy. The only concern I have with any complicated text based format is it can be hard to parse them. But, realistically, it's twenty twenty six, and parsing text is a solved problem.
[01:19:46] Valery Smyslov: I want to clarify. That's some clarification. So first of all, it is you who decide what kind of document do you want to have. So if you are seeking for a standard strict document, then the only way is to try this working group to adopt this document to have some interest in your work. And in this case, you will lose control over the document, and perhaps these attributes will be somehow redefined based on the other other people's in this working group interest. Because if it is only interest for very limited number of people, of course, it's for you, for example, then it's your document. But if it is standards, it must be applicable for other situations too. If you want to publish this as informational RFC, no standard RFC, you can go to independent submission editor. So it's still under your control, and independent submission editor makes just a very simple review, quick review. So it is not a consensus document. And so it's for you to decide which which way is best for WBA. So Okay. Thank you.
[01:21:08] Margaret Cullen: Yeah. I I would I would, caution you, though, that the independent submission editor is not going to publish a radius attribute without talking to the radius working group about whether we think it's and so to Joey's point, which I thank you for making, Joey, but, you know, this this is exactly the question. Right? Is this a standard attribute, which case, Radix should standardize it, or is this a WBA specific thing, in which case I might argue that WBA has its own publication mechanisms. And why why should this go independent submission editor? Are we trying to make it kinda look like a standard RFC? That's really frowned upon. Right? I it's either make it a standard RFC or or an info RFC through the Radext working group, but make it an IETF publication or make it a WBA publication would be my my argument. Right? That really I don't know that we need the independent submissions editor to publish an RFC that's actually a WBA publication because you have your own publications. I so I'd like to understand what line is trying to be drawn there. Like, you know what I mean? What what the what we're what we're going for. I actually don't have an objection fundamentally to the idea that these might these data types might need to be complex and that it might make sense to publish it as an IETF document. I'm not actually against that. So I I'm not trying to say go away. I'm trying to say come here or don't come here. You know?
[01:22:49] Alan DeKok: Yeah. This is Alan. I think the issue with any vendor specific document is that not everyone will read it, pay attention to it, etcetera. If this is a a thing that is more for radius in general, there is utility in publishing it in the IETF.
[01:23:15] Mark: Okay. Thanks for the feedback. Okay. Thank you.
[01:23:32] Valery Smyslov: So I think I think that our agenda is completed for today. So, any other business before we wrap up? Any other question? Open mic. Okay. Thank you for attending our next section at IETF 120, and I think we have a productive session. So I hope we will have soon a new charter and so start working with a bunch of new documents, and I hope we will soon finish. RADIUS/(D)TLS-bis. Long waiting. So thank you. Thank you all very much. We'll see you San Francisco for those who is coming here there. So that's all.