Re: [Nsi-wg] Issue 41 in ogf-nsi-project: Do we replace the replyTo field with a topology/NSA configuration lookup?
Comment #3 on issue 41 by takahiro...@gmail.com: Do we replace the replyTo field with a topology/NSA configuration lookup? http://code.google.com/p/ogf-nsi-project/issues/detail?id=41 I want to use the replyTo field. Currently, all NSA act as requester and provider. In this case, we are able to look up the csProviderEndpoint of requesters easily. However, in near future, some NSA act as only a requester, e.g. PerfSONAR and AutoEarth. It is difficult to describe and manage all requester endpoints as same as provider ones. Moreover, it causes a high barrier to publish new requesters. Therefore, a requester endpoint should be obtained using the replyTo field in the SOAP message payload.
Comment #4 on issue 41 by thost...@gmail.com: Do we replace the replyTo field with a topology/NSA configuration lookup? http://code.google.com/p/ogf-nsi-project/issues/detail?id=41 I agree with Takahiro on this. Until we have a way of handling non-NSA clients (e.g., a querier / visualization tool :-)), the replyTo field is needed as the endpoint cannot be found in the topology. Similarly the requesterNSA field is not usuable for this as it is a urn (and there is no mecanism for mapping non-NSA client to an endpoint (nor can there really be).
Comment #5 on issue 41 by jmacau...@gmail.com: Do we replace the replyTo field with a topology/NSA configuration lookup? http://code.google.com/p/ogf-nsi-project/issues/detail?id=41 This also leads to another point we need to document - NSA should not validate the requestorNSA element. At the moment OpenDRAC validates that the requestorNSA is a valid "nsnetwork" entry in topology. We are now saying that this is not a requirement as previously discussed. Also, the current assumption is that the requestorNSA element can be used to resolve to the physical protocol address of the requesting NSA. So to summarize this discussion: 1. We cannot enforce the requestorNSA to be a valid NSA or NSnetwork entry in topology. 2. The requestorNSA element can't be used to resolve to an endpoint address unless we introduce a formalized mechanism for all clients of the network to also be included in this mechanism. 3. Do we change the requestorNSA to just be an informational field, and therefore, do we need it at all?
Comment #6 on issue 41 by takahiro...@gmail.com: Do we replace the replyTo field with a topology/NSA configuration lookup? http://code.google.com/p/ogf-nsi-project/issues/detail?id=41 Henrik, John, The issue related to the usage of requesterNSA is issue #29. I want to focus on the usage of replyTo and the way to get requester's endpoint in this discussion.
Comment #7 on issue 41 by thost...@gmail.com: Do we replace the replyTo field with a topology/NSA configuration lookup? http://code.google.com/p/ogf-nsi-project/issues/detail?id=41 I agree that the requesterNSA cannot be used for any authN / authZ. The MTL / protocol layer can provide a set of attributes, e.g., IP, certificate identity, etc. These can then be used for authorization. We cannot really use anything in the message for authN / authZ. I also have hard time seeing what we actually need the requeserNSA and providerNSA field for. They seem descriptive / informational to me. In general, the protocol seems to be designed around the assumption that theere is a more or less static set of NSI agents, which only communicates with each other. This is assumption is starting to fall apart as we are starting to use the protocol. There will be clients for querying (e.g., the visualization tool), and it is likely that there will be some short-lived clients requesting connections. There will probably be more. An NSI agent will not always be communicating with another NSI agent.
Comment #8 on issue 41 by jmacau...@gmail.com: Do we replace the replyTo field with a topology/NSA configuration lookup? http://code.google.com/p/ogf-nsi-project/issues/detail?id=41 I was writing some edge test cases and found a related issue. Even if we keep the replyTo field and do not require the requesting NSA to be modelled in topology, we still run into the issue of authentication credentials for the provider NSA to communicate with the requesting NSA. This means we will need to provision these credentials in the providerNSA so that we can establish trust.
Updates: Labels: -FixedInVersion-1.1 FixedInVersion-2.0 Comment #9 on issue 41 by guy.robe...@gmail.com: Do we replace the replyTo field with a topology/NSA configuration lookup? http://code.google.com/p/ogf-nsi-project/issues/detail?id=41 (No comment was entered for this change.)
Updates: Status: WontFix Comment #10 on issue 41 by jmacau...@gmail.com: Do we replace the replyTo field with a topology/NSA configuration lookup? http://code.google.com/p/ogf-nsi-project/issues/detail?id=41 It was decided that the replyTo field will be used to identify when a confirmation response is required, and will be empty when no response is expected. The requesting entity can decide to decouple their confirmation endpoint from the service endpoint if desired. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings
participants (1)
-
ogf-nsi-project＠googlecode.com