I liked most of the changes that were made since the previous revision. A few comments on this draft:
It can't use the IPR declaration that it's using. There is material in here from other drafts (the old diagnostics text) that was submitted prior to 11/2008 and has not been officially reassigned under the new terms. The draft refers to Inspect as Ping. Since there's a Ping method in RELOAD, this is very confusing, especially since I think we've discussed adding a NodeFetch method to support such applications periodically. There currently isn't an option for processing by on-path peers as discussed by 5.4.2. That could be added as a ForwardingOption. Personally I don't like it and would oppose requiring it, but I think that's the right way to proceed with such an idea. This draft could really benefit from a few detailed examples of how to use some of the specific elements. Right now there are ways to query for a lot of different information, but it's not completely clear which elements should be selected for inclusion. For example, you can detect some misrouting with some of these methods, but doing so is quite hard. I think we may want to raise the question of error_info/sub-codes to a separate thread on the list for a general discussion. Given that we have 16 bits for error codes in RELOAD, I'm not sure sub-codes are really needed. Path_Track is sort of a merger of RouteQuery and Fetch. The motivation for defining it as a separate method is, I think, that if you're trying to diagnose route instability, it's helpful to be able to ask those two questions simultaneously before the route changes again. The draft should be a bit clearer on motivating that. _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
