All, Here is a starting point for the list of assumptions for the NSI API. I put these together for our GNI work in the GLIF GNI task force. (please add/delete/modify them as necessary ) Initially the GNI is only implementing three basic calls: 1) CreateReservation 2) CancelReservation 3) ListReservations With these calls we agreed to the following assumptions: 1) Users/NSA should have information regarding the endpoints, such as the type of technology at the interface, and exact location (URI) - this information should be available as either part of the request or the NSA can look it up based on a URI. 2) The NSI API can be used by a client that is an end user/application requesting a multidomain lightpath from an NSA or it can be used by another (“ingress”) NSA making a specific request to a single NRM for a partial path as part of a multidomain lightpath. 3) In some cases the user has a pre-defined chosen route or a preferred next-hop, therefore the API should have feilds available for these two cases. 4) If the technology used at the two endpoints differ, then the NRM/NSA servicing the request is responsible for including technology adaptation. - The API does not explicitly request technology adaptation, it is inferred. 5) It is assumed that the parameters will follow the NML working group language. 6) The API will not be used to exchange topology information. This is all I have at this point, I am sure the list should be longer. Kind regards, Gigi