Hi,
As the authors of the diagnostic draft got ready to iterate, we realized we have to clear up a few issues with the group before we can come up with the next version. There have been comments on list about doing this without creation of new messages, but we also had comments at meetings and some consensus saying that we shouldn't extend the messages that exist and use new ones. While the extensions are minor, it seems like we would need some extensions to accomplish the collection of diagnostic information. We would like to discuss on list which behavior is preferable -- document use of existing messages, but this requires extensions that ideally should be in base, or implement new messages. Simply using existing messages with no extensions doesn't seem to result in being able to have the diagnostic collection abilities we need, so doesn't appear to be a valid option. We'd like to nail down some list discussion, and hopefully discuss this at IETF to get some clear, specific hums on which direction the WG would like to take this work. Essentially, for the "ping" behavior, we need to do we want to be able to do two things -- send a message destined for a particular peer, and find out if a particular resource lives there. How this differs somewhat from the current behavior is in being able to obtain information from the destination (diagnostic information) and being able to capture some on-path information as well. If we reuse existing messages, we can query if a peer exists using ping (and looking at who the response is from), and can query a resource using fetch, but we need additional extensions, (for example in the current draft, hop counts) and need to specify how to request/obtain diagnostic information in the message. The alternative is to use a new method, such as the INSPECT we have proposed in the current draft. Note that the ping message in the base draft is not extensible. For the "traceroute" behavior, which is iterative to collect information, keep the response from being enormous (and to allow for detecting failures on-path), and for security reasons, we have two options. We can send a route query, and then a message to each peer (again, assuming we specify/have support for fetching diagnostic information), or we can use the path_track as defined in the document. They result in slightly different results (using existing messages gets a "snap shot" of a route then checks each hop, so if the route changes, you could be inspecting an invalid path, path_track has exactly the same behavior, but the timing is a bit different as the next step in the route is determined at each hop). It isn't clear to me one is any better than the other. Having a specific diagnostic message will enable future extensions both standard and enterprise specific. The authors feel that it will be better to use specific messages for diagnostics purposes and not to overload the base reload messages. Roni Even
_______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
