> 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
> withoutcreation 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
> extensionsto accomplish the collection of diagnostic information.
> We would like to
> discuss on list which behavior is preferable -- document use of
> existingmessages, but this requires extensions that ideally should
> be in base, or
> implement new messages. Simply using existing messages with no
> extensionsdoesn'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
> resourceusing 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.
>
That means if people want to reuse the existing ping message in the base draft,
it has to be made extensible there(so that it can be used to collect some
diagnostic info, such like hop counts). Or we use an alternative method
(Inspect message in the diagnostic draft). Whatever, we need an explicit
feedback from the WG about which way to go.
>
>
> 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/havesupport 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
> bothstandard 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.
>
We would also like to talk about this question at this meeting.
BR,
Haibin
>
>
>
>
> Roni Even
>
>
>
>
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
