Yes- Everyone remember that there has been a lot worked out the last few days...so please read old email with that in mind... Some of this stuff is ancient history already:-) Jerry On 9/7/11 3:38 PM, John MacAuley wrote:
Looks like mail is starting to come through the NSI-WG mailing list again.
The decision was made to use HTTP and BASIC authentication with a single fixed account.
John.
----- Original Message -----
From: "John MacAuley"<john.macauley@surfnet.nl> To: "Atsuko Takefusa"<takefusa@acm.org> Cc: "NSI WG"<nsi-wg@ogf.org> Sent: Friday, September 2, 2011 11:54:36 AM Subject: Re: [Nsi-wg] NSI service
Can everyone one reply and let me know if they can do https or should we only do http?
I think we should use http basic authentication to secure the session. Can everyone allocate a set of accounts on their system for each of the NSA and send the information to the associated NSA prime?
Thanks, John
Sent from my iPhone
On 2011-09-02, at 10:29 AM, Atsuko Takefusa<takefusa@acm.org> wrote:
Hi Jerry, John, and all,
We will use "urn:ogf:..." values in<requester/providerNSA> and <stpId>, won't we? If so, why do we describe the "urn:ogf:..." values in the .owl file?
And I have a question about security. Which of the followings will we use at Rio?
#1 http + no authentication #2 http + basic authentication (single user name& password) #3 https + basic authentication (single user name& password) #4 other
If #2 or #3, what are the user name and password?
Thanks,
Atsuko
2011/9/2 Jerry Sobieski<jerry@nordu.net>:
Ok good. I agree with what you did...it makes sense to me. And you and I had discussed the NSA topo object. We just need to bring this to the group when we do a Rio post-mortem (:-).
I recall that we decided that the NSA and the Network were separately addressable entities - one was an active agent, and one just represented an administrative/infrastructure domain. Each network has exactly one NSA, and each NSA manages exactly one network. (This does not preclude things like federated structures in the future, but feds require some topological considerations that we have not broached yet.)
Thanks! Jerry
On 9/2/11 9:00 AM, John MacAuley wrote:
You are correct - copy and paste issue. It should be urn:ogf:network:nsa:Martinique-DynamicKL. I can't remember if we decided to use the network to define the NSA, but in the topology we need to uniquely name the NSA and it can't conflict with the network name. I made the leap of faith that we should then use this NSA name in the NSA fields. John. On 2011-09-02, at 8:49 AM, Jerry Sobieski wrote:
Hey John - question about the requesterNSA/providerNSA fields...see comment in line..
On 9/2/11 8:30 AM, John MacAuley wrote:
Looks like I have some explaining to do. We forget that not everyone is participating in the NSI weekly meetings and the extra special OGF conference meetings. Lucky for you, but unfortunately you miss the results of some of the discussions. The is only one SOAP endpoint in the message and that is in the replyTo field. We originally didn't have the replyTo field and the endpoints were in the requesterNSA and providerNSA fields, however, there was a push to make these field protocol independent. I wrote the new topology schema a couple of weeks ago so this is the first time a SOAP endpoint had shown up in the schema. Mainly for discovering the ProviderNSA endpoint. This will remove manual provisioning of the endpoint in each NSA. Howeve, now that we have this topology mechanism, we could expand it to hold the Requestor endpoint as well, removing the need for the replyTo field.
Here is what a request should look like based on all the agreements we have reached. We need to make sure everyone follows this pattern or chaos will prevail :-) <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:int="http://schemas.ogf.org/nsi/2011/07/connection/interface" xmlns:typ="http://schemas.ogf.org/nsi/2011/07/connection/types" xmlns:urn="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xe="http://www.w3.org/2001/04/xmlenc#" xmlns:xd="http://www.w3.org/2000/09/xmldsig#"> <soapenv:Header/> <soapenv:Body> <int:reservationRequest> <int:correlationId>urn:uuid:73d32a9d-fc68-4736-9c24-99abce1aaea3</int:correlationId> <int:replyTo>http://orval.grid.aau.dk:7080/NSI/services/ConnectionService</int:replyTo> <typ:reservation> <requesterNSA>urn:ogf:network:nsa:Aruba-OpenNSA</requesterNSA> <providerNSA>urn:ogf:network:NSnetwork:Martinique-DynamicKL</providerNSA>
Right here ^ Why do you specify an NSA URN in the requesterNSA field but specify a Network in the provider NSA field ?? These should both be NSA references. Right?
Also, at SLC, we did not define an "NSA" URN...not that I recall. Did we? I think what you have will work nicely for now, but I don't think it is in the spec. (?) Therefore, we should put this on the near term dicussion list to get group consesnsus. (we touched only on the Network <not equal> NSA issue, but not how that should be done or what the mapping supports, etc.)
<reservation> <globalReservationId>urn:ogf:network:service:Aruba:conn-560</globalReservationId>
<description>OpenNSA Test Schedule #1</description> <connectionId>urn:uuid:593d9816-0574-471d-b2a9-101e63a5d0f2</connectionId> <serviceParameters> <schedule> <startTime>2011-10-15T21:32:52+01:00</startTime> <endTime>2011-10-15T22:32:52+01:00</endTime> </schedule> <bandwidth> <desired>100</desired> </bandwidth> </serviceParameters> <path> <directionality>Bidirectional</directionality> <sourceSTP> <stpId>urn:ogf:network:NSnetwork:Martinique:M1</stpId> </sourceSTP> <destSTP> <stpId>urn:ogf:network:NSnetwork:Martinique:M4</stpId> </destSTP> </path> </reservation> </typ:reservation> </int:reservationRequest> </soapenv:Body> </soapenv:Envelope>
On 2011-09-02, at 5:45 AM, Henrik Thostrup Jensen wrote:
On Wed, 31 Aug 2011, John MacAuley wrote:
Yes you can combine them if you need to. But I think the protocol will work without them combined. The csProviderEndpoint value tells the RA how to contact the PA for a network. The RA fills in the replyTo field within the SOAP request to tell the PA how to respond with the confirmation, failed, or forcedEnd messages.
I combine the endpoints in OpenNSA, but as I interpret the protocol, this is not a requirement at all, and the protocol explicitely supports different endpoitns for this.
It is important to note, that the RA endpoint is only advertised through the replyTo field (AFAIK), and never in the topology and requester / provider fields.
Comments?
I find that there are way to many addressing schemes. Currently there is:
A. NSA provider endpoint advertisted through topology. B. NSA provider and requester endpoint specified in provider/requester message fields. C. NSA requester endpoint specified in replyTo message field.
Which is simply to many IMHO.
I think the providerNSA and requesterNSA fields in the message could be removed entirely without problems (these fields smell alot like some low level protocol where security is not an issue - which is not the case for NSI at all).
I would also like to see the removal of the replyTo field, such that an NSA only has one contact point - the one advertised through the topology.
Best regards, Henrik
Henrik Thostrup Jensen<htj at ndgf.org> NORDUnet / Nordic Data Grid Facility._______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
-- Atsuko Takefusa Information Technology Research Institute, AIST
nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg