Hi, > On 4 Apr 2024, at 10:34, Jen Linkova <furry13@xxxxxxxxx> wrote: > > On Thu, Apr 4, 2024 at 7:06 PM Tim Chown <Tim.Chown@xxxxxxxxxx> wrote: >>> The thing is that the host behaviour is explicitly (and intentionally) >>> out of scope. For me, as a network administrator, it doesn't matter >>> how exactly the client configures that address: my network >>> design/topology would be the same. The client can be a RFC7084-type >>> router (that's what happens when someone plugs a CPE to an access >>> port), or use smth like rfc7278 - or smth else. Up to the client, the >>> network routes thet whole prefix to that device, do whatever you want >>> with it. >> >> OK, so maybe make it clearer that it is out of scope, as I was expecting to find some comment about it, and I could not. > > The last paragraph of the Introduction states that: > "This document focuses on the behaviour of the network. Host behaviour > is not defined in this document." > Do you think we need to make it more clear? Sorry, I missed that, but the question of how more precisely this model would be deployed in, for example, a campus WiFi network, would be worth documenting. How addresses on the wireless side are configured, how the routing is done, whether a mixed environment is practical, interactions with eduroam (802.1x), that sort of thing. Perhaps that’s a second informational document. >> we do frequently have campus admins asking how they get host entries into the DNS with SLAAC, so it’s a FAQ. > > Yes, I agree it's a problem to solve, but I think it might be more in > scope for my 6MOPS draft...What do you think? Sounds fine :) There’s also probably something to be said somewhere about address accountability, it’s the flip side of the privacy considerations but useful in a campus environment. I don’t think the draft mentions this (or at least has one unrelated instance of the word ‘account’). Best wishes, Tim -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
