Updates: Labels: -FoundInVersion-1.0 -FixedInVersion-1.sc FoundInVersion-1.sc FixedInVersion-2.0 Comment #3 on issue 49 by guy.robe...@gmail.com: Missing information in detailed query? http://code.google.com/p/ogf-nsi-project/issues/detail?id=49 (No comment was entered for this change.)

Comment #5 on issue 49 by jmacau...@gmail.com: Missing information in detailed query? http://code.google.com/p/ogf-nsi-project/issues/detail?id=49 I investigate the current data returned by the query operation. The QuerySummaryResultType contains the overall connection state as viewed by the NSA being queried. It also contains a PathList that provides a summary of the STPs. This may be a pair of STP associated with the connection, or a more detailed path list of STP. However, it does not contain information about the children NSA involved in this connection. To get the detailed path information you must issue a recursive query to get a QueryDetailsResultType back with the detailed list of NSA involved in the request tree. Is it desirable to modify the QuerySummaryResultType to return the list of immediate children to the queried NSA involved in the connection reservation?

Comment #7 on issue 49 by jmacau...@gmail.com: Missing information in detailed query? http://code.google.com/p/ogf-nsi-project/issues/detail?id=49 Time to update this open issue with additional notes. Description of Issue: The QueryConfirmed response for Summary results needs to return the list of child connectionId and the associated providerNSA for the connections if this reservation was broken down further. Discussion of Issue: The current reservationSummary type retuned in the QueryConfirmed response contains the target NSA's view of a connection reservation. This includes basic reservation parameters (ReservationInfoGroup), the connectionState as known by the target NSA, and the simple path the reservation took also based on the target NSA's view. There are three problems with the data returned: 1. The reservationSummary does not indicate if the target NSA is the root of the reservation, or a child in a reservation tree (i.e. the parent (requester) NSA is not identified if it exists. Issue 63 was created to track this defect. 2. There is no indication if the reservation was further broken down into child NSA requests, and if it was, the connectionId and providerNSA associated with each child reservation. This issue was created to track this specific defect. 3. The path object is ambiguous and may not clearly describe the true direction of the path used in the reservation. We will need a new issue to track this one. There are three proposals for a solution to this issue: 1. Enhance the existing QuerySummaryResultType to include the local view of the reservation and the local view of the child connections (providerNSA, connectionId, and perhaps derived connectionState). 2. Introduce a third message that would provide this additional local detail. 3. Support one message and specify a depth for the query. Depth 0 would be the local NSA. Depth 1 would be local NSA plus one level of children deep in the tree. Solution #1 provides desired information, but makes the summary query for simple state a bit more complex by including the additional child summary connection information. Can we accept the additional overhead? Solution #2 provides the additional local connection information similar to #1 but in a new QueryConfirmed response. Do we want to introduce another query result type? Solution #3 reduces the number of responses to a single message, however, it will require the additional local information to be included even when doing a recursive query down the tree since we are using a single result structure, and the information needs to be included when depth is 0.