Peoples, I was cleaning up the WSDL specific definitions and forgot if I was suppose to remove the transactionId from the CS XSD and move it to the WSDL protocol specification? <xsd:element name="transactionId" type="xsd:string"/> Does anyone care if I move it out? Thank you, John. On 2011-04-19, at 8:31 AM, Jerry Sobieski wrote:
Hi Inder and all-
I've been thinking hard on these topics below. I am still unsure as to the correctness of some of our decisions here, but I will concede several of these in order to move v1.0 forward.
- underspec'd endpoints IMO: This is workable concept and very promising and I like it - but requires a considerable discussion regarding topology and endpoint semantics that we have not had yet and that will take a while to work out. I think the breadth (and power) of this concept will surprise us, so I want to do it well. So my recommendation is that we do not do something now that prevents this, but we should not try to work this out in V1.0 - this is a new feature. For v1.0, leave the endpoint to be an endpoint. I think a lot of this issue will be worked out relatively easily in conjunction with NSI topology. The CS protocol does not *need* this to be fully functional and entirely workable. ( The concerns that have been voiced are actually topology and pathfinding issues - and I think we can resolve these better and more completely in the ensuing topology discussion.)
- NSA and NSI Network name equivalence I will concede this issue. I still am not certain this is the correct course to take, but since we *do* use the NSA and Network interchangeably so often, perhaps we will not run afoul of their differences. I would ask that we keep this issue in mind and if we find a compelling aspect that dictates these be separated, that we reconsider the issue. But lets assume for v1.0 that the "NSI Network name" and the "NSA_ID" are the same object. - NSA indirection I think we agree that the NSA_ID==Network Name. But the contact information for the NSA/Network is not encoded in the name itself. The NSA contact info is *associated* with the network name but requires one level of indirection (a look up) to go from <name> to <contact info>.
- Network name: Opaque string or URN? IMO: Opaque string. For now. I am certain that we will have more specific requirements when we get to NSI topology and/or pathfinding discussions. If those discussions benefit from or require a specific format, I will go willingly:-) But for now, NSI-CS only requires the Network name to be unique so that endpoints are uniquely mapped to one and only one NSA. The NSI-CS requirement is only uniqueness, so lets not impose more - particularly when we have other undefined protocols that may have some requirements as well. Since we do not know of other uses of the Network name, we should leave it as unspecified as possible. It is sufficient for NSI-CS to say "The Network name is assumed to be a string that uniquely identifies a single particular NSI network." Thats all we need. (This allows URNs, DNS names, ISBN numbers, ... as long as it uniquely identifies a single NSI network.) If the group does insist on specific format(s) e.g. URN, I will accept it. But then we must also specify the registry. And we should also specify how NSI verifies the name is conformant to the required format(s) since it is explicitly necessary that Network Names have those formats.
- NSA/Network ID authentication We have not addressed this, but this may be necessary to insure no two NSAs claim the same [unique] network name. This goes to some of my reservations about URNs and network names - a unique name does not prevent two agents from using it. How do we insure a network name is unique - and in what context (topology representation? trust extablishment? etc.) I think this is a topology discussion. But that we will need to define a mechanism that allows an NSA to authenticate a remote NSA as the authoritative NSA for the associated network. Which implies a linkage beween the Network name and the authorization credentials. Has anyone explicitly considered this as part of the trust establishment? Does this go far enough?
- simple user NSAs We do not have resolution on how a simple user RA should identify itself. Since this simple user RA has no network, what network name should it use as its NSA_ID in its messaging? Since the user NSA has no network, it has then no endpoints, and the endpoints in the request are therefore not in its "network"...therefore, no uniqueness is required unless some far remote NSA needs to contact it...Since the simple User RA has no trust with any other NSA, this seems unlikely to happen. So can we use a non-unique network name? Can we ask the PA to assign a "local Network name" to be used for this connection? Without resolving this issue, all simple user NSAs will need to acquire a globally unique network name in order to particiapte in NSI. If we could allow simple users without networks to avaod registering a unique network name, it would make it far simpler for adoption...and I don't think it would be difficult to do this or break/change the rest of the protocol. Thoughts?
I hope this helps. Jerry
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg