IETF
roll@jabber.ietf.org
Wednesday, July 6, 2016< ^ >
mcr/credil has set the subject to: IETF96 ROLL WG meeting
Room Configuration
Room Occupants

GMT+0
[00:08:59] mcr/soho joins the room
[17:12:57] Michael Richardson joins the room
[18:40:14] Michael Richardson leaves the room: Disconnected: Replaced by new connection
[18:40:14] Michael Richardson joins the room
[21:21:03] eintopf joins the room
[21:21:11] <eintopf> huhu
[21:22:41] <eintopf> I thought again about right updating the short address for a neighbour
[21:23:33] <eintopf> and I think the real question is: "How can you broadcast (over RS/RA/NS/NA) address option fields, that the node doesn't has a short address anymore?
[21:24:07] <eintopf> I currently do that, if there is no short address address option in RS/RA/NS/NA, then the neighbour doesn't has a short address anymore
[21:24:09] <eintopf> BUT
[21:24:26] <eintopf> this require that all messages types adds a RS/RA/NS/NA short address option
[21:24:46] <eintopf> on RA this is problematic because the userspace software need to have support for that
[21:25:31] <eintopf> and it's a complete new use-case, you cannot say "how this is done by extended unique addresses", it's different because short address handling is optional
[21:26:41] <eintopf> and if there is no address option for the extended address the handling differs here, it's use the address which is currently in the neighbour cache (if the address option is not available in RS/RA/NS/NA)
[21:27:13] <eintopf> we can do that also, but then again "How can you broadcast (over RS/RA/NS/NA) address option fields, that the node doesn't has a short address anymore?"
[21:29:07] <eintopf> because it could be that the node updates his short address to something -> the node doesn't has a short address anymore
[21:29:22] <eintopf> on extended address this is impossible
[21:29:34] <eintopf> at*
[21:49:16] eintopf leaves the room: Disconnected: closed
[23:47:14] <mcr/soho> this is worth bringing up in 6lo.  Do you want me to do that?
[23:48:29] <mcr/soho> starting email.
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!