Peoples, Here is the latest (and I hope the last) update to the WSDL. John. Version 0.09 Changes to NSI WSDL specification Date: August 6, 2011 Author: John MacAuley 1. Changed all occurrences of Requestor to Requester in the documentation, names, and bindings. 2. Capitalized enumerated values in DirectionalityType to "Bidirectional" and "Unidirectional". 3. Set directionality default to "Bidirectional". 4. Added connectionState to DetailedPathType so each NSA down the tree will provide its view of the state machine. 5. Modified ReservationConfirmedType to return only summary reservation information and not the detailed path. 5. Created new QueryOperationType with values "Summary" and "Details" to allow modeling of two separate query operations. The "Summary" operation matches the behavior of our original query on level deep in the tree, while "Details" performs a recursive query down the tree to build a complete path view from all children. 6. Modified the QueryFilterType to use QueryOperationType allowing the requester to specify if summary or detailed path results should be returned. 7. Restructured the QueryConfirmedType to support returning of a choice of summary reservation information or detailed path results. 8. Created QuerySummaryResultType to hold the query summary results. 9. Removed DetailedReservationInfoGroup to QueryDetailsResultType to hold the recursive path query results. 10. Modified QueryConfirmedType to return a choice of reservationSummary or reservationDetails. 11. Removed AttributeSequenceType and replaced with saml:AttributeStatementType to avoid naming conflicts with AttributeType definition with exists in both namespaces. 12. Removed SubjectAttributeSequenceType and replaced with equivalent saml:AttributeStatementType. ---------------
Hi John, We have a question: If multiple connection ids are specified in a query message, and one or more of them are invalid (non-exist) ids, should the query fail? Or, just return an array with null elements? Thanks, Tomohiro On Mon, 8 Aug 2011 17:47:50 -0400 John MacAuley <john.macauley@surfnet.nl> wrote:
Peoples,
Here is the latest (and I hope the last) update to the WSDL.
John.
Version 0.09 Changes to NSI WSDL specification Date: August 6, 2011 Author: John MacAuley
1. Changed all occurrences of Requestor to Requester in the documentation, names, and bindings. 2. Capitalized enumerated values in DirectionalityType to "Bidirectional" and "Unidirectional". 3. Set directionality default to "Bidirectional". 4. Added connectionState to DetailedPathType so each NSA down the tree will provide its view of the state machine. 5. Modified ReservationConfirmedType to return only summary reservation information and not the detailed path. 5. Created new QueryOperationType with values "Summary" and "Details" to allow modeling of two separate query operations. The "Summary" operation matches the behavior of our original query on level deep in the tree, while "Details" performs a recursive query down the tree to build a complete path view from all children. 6. Modified the QueryFilterType to use QueryOperationType allowing the requester to specify if summary or detailed path results should be returned. 7. Restructured the QueryConfirmedType to support returning of a choice of summary reservation information or detailed path results. 8. Created QuerySummaryResultType to hold the query summary results. 9. Removed DetailedReservationInfoGroup to QueryDetailsResultType to hold the recursive path query results. 10. Modified QueryConfirmedType to return a choice of reservationSummary or reservationDetails. 11. Removed AttributeSequenceType and replaced with saml:AttributeStatementType to avoid naming conflicts with AttributeType definition with exists in both namespaces. 12. Removed SubjectAttributeSequenceType and replaced with equivalent saml:AttributeStatementType.
---------------
Tomohiro, The decision in SLC was that a queryConfirmed would be returned with no results for the connectionID or globalReservationId that did not match. If you send 10 connectionIds in a query request and get only five results, then you can derive that 5 connectionIds did not match reservations. The only time a queryFailed is returned is if there is a true error and never for a non-match. John. On 2011-08-09, at 11:42 AM, Tomohiro Kudoh wrote:
Hi John,
We have a question:
If multiple connection ids are specified in a query message, and one or more of them are invalid (non-exist) ids, should the query fail? Or, just return an array with null elements?
Thanks,
Tomohiro
On Mon, 8 Aug 2011 17:47:50 -0400 John MacAuley <john.macauley@surfnet.nl> wrote:
Peoples,
Here is the latest (and I hope the last) update to the WSDL.
John.
Version 0.09 Changes to NSI WSDL specification Date: August 6, 2011 Author: John MacAuley
1. Changed all occurrences of Requestor to Requester in the documentation, names, and bindings. 2. Capitalized enumerated values in DirectionalityType to "Bidirectional" and "Unidirectional". 3. Set directionality default to "Bidirectional". 4. Added connectionState to DetailedPathType so each NSA down the tree will provide its view of the state machine. 5. Modified ReservationConfirmedType to return only summary reservation information and not the detailed path. 5. Created new QueryOperationType with values "Summary" and "Details" to allow modeling of two separate query operations. The "Summary" operation matches the behavior of our original query on level deep in the tree, while "Details" performs a recursive query down the tree to build a complete path view from all children. 6. Modified the QueryFilterType to use QueryOperationType allowing the requester to specify if summary or detailed path results should be returned. 7. Restructured the QueryConfirmedType to support returning of a choice of summary reservation information or detailed path results. 8. Created QuerySummaryResultType to hold the query summary results. 9. Removed DetailedReservationInfoGroup to QueryDetailsResultType to hold the recursive path query results. 10. Modified QueryConfirmedType to return a choice of reservationSummary or reservationDetails. 11. Removed AttributeSequenceType and replaced with saml:AttributeStatementType to avoid naming conflicts with AttributeType definition with exists in both namespaces. 12. Removed SubjectAttributeSequenceType and replaced with equivalent saml:AttributeStatementType.
---------------
Should there be just 5 results or 10 results of which 5 with asked connection IDs, and NULL state? Inder
------------------------------------------------------------------------
John MacAuley <mailto:john.macauley@surfnet.nl> August 9, 2011 5:28 PM
Tomohiro,
The decision in SLC was that a queryConfirmed would be returned with no results for the connectionID or globalReservationId that did not match. If you send 10 connectionIds in a query request and get only five results, then you can derive that 5 connectionIds did not match reservations.
The only time a queryFailed is returned is if there is a true error and never for a non-match.
John.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg ------------------------------------------------------------------------
Tomohiro Kudoh <mailto:t.kudoh@aist.go.jp> August 9, 2011 8:42 AM
Hi John,
We have a question:
If multiple connection ids are specified in a query message, and one or more of them are invalid (non-exist) ids, should the query fail? Or, just return an array with null elements?
Thanks,
Tomohiro
On Mon, 8 Aug 2011 17:47:50 -0400
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg ------------------------------------------------------------------------
John MacAuley <mailto:john.macauley@surfnet.nl> August 8, 2011 2:47 PM
Peoples,
Here is the latest (and I hope the last) update to the WSDL.
John.
Version 0.09 Changes to NSI WSDL specification Date: August 6, 2011 Author: John MacAuley
1. Changed all occurrences of Requestor to Requester in the documentation, names, and bindings. 2. Capitalized enumerated values in DirectionalityType to "Bidirectional" and "Unidirectional". 3. Set directionality default to "Bidirectional". 4. Added connectionState to DetailedPathType so each NSA down the tree will provide its view of the state machine. 5. Modified ReservationConfirmedType to return only summary reservation information and not the detailed path. 5. Created new QueryOperationType with values "Summary" and "Details" to allow modeling of two separate query operations. The "Summary" operation matches the behavior of our original query on level deep in the tree, while "Details" performs a recursive query down the tree to build a complete path view from all children. 6. Modified the QueryFilterType to use QueryOperationType allowing the requester to specify if summary or detailed path results should be returned. 7. Restructured the QueryConfirmedType to support returning of a choice of summary reservation information or detailed path results. 8. Created QuerySummaryResultType to hold the query summary results. 9. Removed DetailedReservationInfoGroup to QueryDetailsResultType to hold the recursive path query results. 10. Modified QueryConfirmedType to return a choice of reservationSummary or reservationDetails. 11. Removed AttributeSequenceType and replaced with saml:AttributeStatementType to avoid naming conflicts with AttributeType definition with exists in both namespaces. 12. Removed SubjectAttributeSequenceType and replaced with equivalent saml:AttributeStatementType.
--------------- _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
-- Inder Monga 510-486-6531 http://www.es.net Follow us on Twitter: ESnetUpdates/Twitter <http://bit.ly/bisCAd> Visit our blog: ESnetUpdates Blog <http://bit.ly/9lSTO3> Facebook: ESnetUpdates/Facebook <http://bit.ly/d2Olql>
I do not have it defined that way but if you think returning a null data set only filled with the connectionId then we could do that. So what do you think would happen if 5 can be viewed and 5 cannot be viewed do to authorization permissions? Would this have the same result? I would think so given we do not what to let the querying NSA know the connections exist. John. On 2011-08-10, at 4:54 AM, Inder Monga wrote:
Should there be just 5 results or 10 results of which 5 with asked connection IDs, and NULL state?
Inder
John MacAuley August 9, 2011 5:28 PM
Tomohiro,
The decision in SLC was that a queryConfirmed would be returned with no results for the connectionID or globalReservationId that did not match. If you send 10 connectionIds in a query request and get only five results, then you can derive that 5 connectionIds did not match reservations.
The only time a queryFailed is returned is if there is a true error and never for a non-match.
John.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Tomohiro Kudoh August 9, 2011 8:42 AM
Hi John,
We have a question:
If multiple connection ids are specified in a query message, and one or more of them are invalid (non-exist) ids, should the query fail? Or, just return an array with null elements?
Thanks,
Tomohiro
On Mon, 8 Aug 2011 17:47:50 -0400
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
John MacAuley August 8, 2011 2:47 PM
Peoples,
Here is the latest (and I hope the last) update to the WSDL.
John.
Version 0.09 Changes to NSI WSDL specification Date: August 6, 2011 Author: John MacAuley
1. Changed all occurrences of Requestor to Requester in the documentation, names, and bindings. 2. Capitalized enumerated values in DirectionalityType to "Bidirectional" and "Unidirectional". 3. Set directionality default to "Bidirectional". 4. Added connectionState to DetailedPathType so each NSA down the tree will provide its view of the state machine. 5. Modified ReservationConfirmedType to return only summary reservation information and not the detailed path. 5. Created new QueryOperationType with values "Summary" and "Details" to allow modeling of two separate query operations. The "Summary" operation matches the behavior of our original query on level deep in the tree, while "Details" performs a recursive query down the tree to build a complete path view from all children. 6. Modified the QueryFilterType to use QueryOperationType allowing the requester to specify if summary or detailed path results should be returned. 7. Restructured the QueryConfirmedType to support returning of a choice of summary reservation information or detailed path results. 8. Created QuerySummaryResultType to hold the query summary results. 9. Removed DetailedReservationInfoGroup to QueryDetailsResultType to hold the recursive path query results. 10. Modified QueryConfirmedType to return a choice of reservationSummary or reservationDetails. 11. Removed AttributeSequenceType and replaced with saml:AttributeStatementType to avoid naming conflicts with AttributeType definition with exists in both namespaces. 12. Removed SubjectAttributeSequenceType and replaced with equivalent saml:AttributeStatementType.
--------------- _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
-- Inder Monga 510-486-6531 http://www.es.net Follow us on Twitter: ESnetUpdates/Twitter Visit our blog: ESnetUpdates Blog Facebook: ESnetUpdates/Facebook
How do you prevent fishing? Ie querying for connections just to see if they exist. Seems to me authorization policy dictates what should be generally knowable about a real/fictitious connection. ?? J Sent from my iPhone On Aug 10, 2011, at 7:47 AM, John MacAuley <john.macauley@surfnet.nl> wrote:
I do not have it defined that way but if you think returning a null data set only filled with the connectionId then we could do that.
So what do you think would happen if 5 can be viewed and 5 cannot be viewed do to authorization permissions? Would this have the same result? I would think so given we do not what to let the querying NSA know the connections exist.
John.
On 2011-08-10, at 4:54 AM, Inder Monga wrote:
Should there be just 5 results or 10 results of which 5 with asked connection IDs, and NULL state?
Inder
John MacAuley August 9, 2011 5:28 PM
Tomohiro,
The decision in SLC was that a queryConfirmed would be returned with no results for the connectionID or globalReservationId that did not match. If you send 10 connectionIds in a query request and get only five results, then you can derive that 5 connectionIds did not match reservations.
The only time a queryFailed is returned is if there is a true error and never for a non-match.
John.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Tomohiro Kudoh August 9, 2011 8:42 AM
Hi John,
We have a question:
If multiple connection ids are specified in a query message, and one or more of them are invalid (non-exist) ids, should the query fail? Or, just return an array with null elements?
Thanks,
Tomohiro
On Mon, 8 Aug 2011 17:47:50 -0400
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
John MacAuley August 8, 2011 2:47 PM
Peoples,
Here is the latest (and I hope the last) update to the WSDL.
John.
Version 0.09 Changes to NSI WSDL specification Date: August 6, 2011 Author: John MacAuley
1. Changed all occurrences of Requestor to Requester in the documentation, names, and bindings. 2. Capitalized enumerated values in DirectionalityType to "Bidirectional" and "Unidirectional". 3. Set directionality default to "Bidirectional". 4. Added connectionState to DetailedPathType so each NSA down the tree will provide its view of the state machine. 5. Modified ReservationConfirmedType to return only summary reservation information and not the detailed path. 5. Created new QueryOperationType with values "Summary" and "Details" to allow modeling of two separate query operations. The "Summary" operation matches the behavior of our original query on level deep in the tree, while "Details" performs a recursive query down the tree to build a complete path view from all children. 6. Modified the QueryFilterType to use QueryOperationType allowing the requester to specify if summary or detailed path results should be returned. 7. Restructured the QueryConfirmedType to support returning of a choice of summary reservation information or detailed path results. 8. Created QuerySummaryResultType to hold the query summary results. 9. Removed DetailedReservationInfoGroup to QueryDetailsResultType to hold the recursive path query results. 10. Modified QueryConfirmedType to return a choice of reservationSummary or reservationDetails. 11. Removed AttributeSequenceType and replaced with saml:AttributeStatementType to avoid naming conflicts with AttributeType definition with exists in both namespaces. 12. Removed SubjectAttributeSequenceType and replaced with equivalent saml:AttributeStatementType.
--------------- _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
-- Inder Monga 510-486-6531 http://www.es.net Follow us on Twitter: ESnetUpdates/Twitter Visit our blog: ESnetUpdates Blog Facebook: ESnetUpdates/Facebook
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
I we are consistent in returning query results for connectionIds that do not match and connectionIds they are not authorized to see, then fishing will not work. I guess this means we want to send back authorization failed messages only when users are not permitted to query, and not when they are unauthorized to view a reservation. John. On 2011-08-10, at 8:08 AM, Jerry Sobieski wrote:
How do you prevent fishing? Ie querying for connections just to see if they exist. Seems to me authorization policy dictates what should be generally knowable about a real/fictitious connection. ?? J
Sent from my iPhone
On Aug 10, 2011, at 7:47 AM, John MacAuley <john.macauley@surfnet.nl> wrote:
I do not have it defined that way but if you think returning a null data set only filled with the connectionId then we could do that.
So what do you think would happen if 5 can be viewed and 5 cannot be viewed do to authorization permissions? Would this have the same result? I would think so given we do not what to let the querying NSA know the connections exist.
John.
On 2011-08-10, at 4:54 AM, Inder Monga wrote:
Should there be just 5 results or 10 results of which 5 with asked connection IDs, and NULL state?
Inder
John MacAuley August 9, 2011 5:28 PM
Tomohiro,
The decision in SLC was that a queryConfirmed would be returned with no results for the connectionID or globalReservationId that did not match. If you send 10 connectionIds in a query request and get only five results, then you can derive that 5 connectionIds did not match reservations.
The only time a queryFailed is returned is if there is a true error and never for a non-match.
John.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Tomohiro Kudoh August 9, 2011 8:42 AM
Hi John,
We have a question:
If multiple connection ids are specified in a query message, and one or more of them are invalid (non-exist) ids, should the query fail? Or, just return an array with null elements?
Thanks,
Tomohiro
On Mon, 8 Aug 2011 17:47:50 -0400
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
John MacAuley August 8, 2011 2:47 PM
Peoples,
Here is the latest (and I hope the last) update to the WSDL.
John.
Version 0.09 Changes to NSI WSDL specification Date: August 6, 2011 Author: John MacAuley
1. Changed all occurrences of Requestor to Requester in the documentation, names, and bindings. 2. Capitalized enumerated values in DirectionalityType to "Bidirectional" and "Unidirectional". 3. Set directionality default to "Bidirectional". 4. Added connectionState to DetailedPathType so each NSA down the tree will provide its view of the state machine. 5. Modified ReservationConfirmedType to return only summary reservation information and not the detailed path. 5. Created new QueryOperationType with values "Summary" and "Details" to allow modeling of two separate query operations. The "Summary" operation matches the behavior of our original query on level deep in the tree, while "Details" performs a recursive query down the tree to build a complete path view from all children. 6. Modified the QueryFilterType to use QueryOperationType allowing the requester to specify if summary or detailed path results should be returned. 7. Restructured the QueryConfirmedType to support returning of a choice of summary reservation information or detailed path results. 8. Created QuerySummaryResultType to hold the query summary results. 9. Removed DetailedReservationInfoGroup to QueryDetailsResultType to hold the recursive path query results. 10. Modified QueryConfirmedType to return a choice of reservationSummary or reservationDetails. 11. Removed AttributeSequenceType and replaced with saml:AttributeStatementType to avoid naming conflicts with AttributeType definition with exists in both namespaces. 12. Removed SubjectAttributeSequenceType and replaced with equivalent saml:AttributeStatementType.
--------------- _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
-- Inder Monga 510-486-6531 http://www.es.net Follow us on Twitter: ESnetUpdates/Twitter Visit our blog: ESnetUpdates Blog Facebook: ESnetUpdates/Facebook
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
participants (4)
-
Inder Monga -
Jerry Sobieski -
John MacAuley -
Tomohiro Kudoh