JRC transmission error handling of Parameter Update Requests

Tag: WGLC

Xavier Vilajosana wrote (https://mailarchive.ietf.org/arch/msg/6tisch/ZrfodE6d3dcRm8LrH-JhUcKX5yM):

2) The JRC is the origin of Parameter Update Requests which may contain for example rekeying material or a new short address. The draft needs to describe what happens if the destination 6N is not reachable. I understand that there will be a timeout and possibly will retry later or do not try anymore (this has to be stated). What if the node is no more in the network? when the JRC will stop sending the short address updates? When it will remove that node from its "database"?

What you propose is indeed something that an implementor must consider but I am not sure if we want to specify any particular behavior in the draft, since this seems to be more of a policy.

I can add explicit text discussing this issue, but leaving it up to the implementation of the JRC to decide how transmission errors of CoAP CON message, that is Parameter Update Request, should be handled. What do you think?

I think that identifying the issue is important so implementers can take it into account.

Comments (2)