[Nsi-wg] Please begin testing

[John MacAuley]

I just need HTTPS.  I am not authenticating the client.

I will send back to the endpoint in the format requested in the replyTo field.

John.

On 2011-11-02, at 9:52 AM, Tomohiro Kudoh wrote:

> So, John, could you please clarify how https should be supported by aggregators?
> 
> - Do you need just https (SSL/TLS)? Or, is client authentication required?
> 
> - As a providerNSA, can you use http to send back confirm/fail message
> to a requester?
> 
> Tomohiro
> 
> 2011/11/2 Jerry Sobieski <jerry at nordu.net>:
>> Hi All-
>> 
>> I did not mean to imply everyone had to implement an HTTPS interface - I
>> just meant the issue needs to be resolved and the solution tested.
>> 
>> The Spec says "authenticated and secure" - but it does not require HTTPS.
>> So we are in grey area.    For the SC demo we will do the following:
>> 
>> 1- The Aggregator NSAs *should* implement both HTTPS and HTTP transports for
>> their RA.  This will allow them to segment requests to either type of PA.
>> The aggregator NSAs are G-LAMBDA-A, AutoBAHN, and OpenNSA.  (OpenNSA plans
>> to implement both modes for the RA for the SC demo...but will be close.  TK:
>> What about GL-A?  RK: Is this possible for AB prior to SC?
>> 
>> 2- For the SC demo, PAs can do either HTTP or HTTPS.  The RA client must be
>> able to conform to the PA they intend to interact with.
>> 
>> If your client RA is HTTP only, and it wants to interact with a HTTPS only
>> PA, it can forward its primitive request to an HTTP Aggregator PA which will
>> "segment" the request and send it to the HTTPS PA.  This adds one layer to
>> the service tree, but is otherwise is a fully compliant property of the
>> protocol.
>> 
>> Does this help resolve the problem?
>> Jerry
>> 
>> 
>> On 11/2/11 4:18 AM, Radek Krzywania wrote:
>>> 
>>> Hi,
>>> I agree with Tomohiro. We spent a lot of time fighting with dataplane for
>>> FIA demo, instead of working with NSI protocol itself. We still do not have
>>> HTTPS and can’t talk with DRAC at NetherLight, who is direct peer and GEANT
>>> related NRENS way to US and Japan. It's critical for us. I would appreciate
>>> if for SC demo we could use HTTP mode as well.
>>> 
>>> Best regards
>>> Radek
>>> 
>>> ________________________________________________________________________
>>> Radoslaw Krzywania                      Network Research and Development
>>>                                            Poznan Supercomputing and
>>> radek.krzywania at man.poznan.pl                   Networking Center
>>> +48 61 850 25 26                             http://www.man.poznan.pl
>>> ________________________________________________________________________
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Tomohiro Kudoh [mailto:t.kudoh at aist.go.jp]
>>>> Sent: Wednesday, November 02, 2011 5:36 AM
>>>> To: Jerry Sobieski
>>>> Cc: t.kudoh at aist.go.jp; nsi-plugfest at m.aist.go.jp; automatedgole-
>>>> pilot at internet2.edu; nsi-wg at ogf.org
>>>> Subject: Re: [Nsi-wg] Please begin testing
>>>> 
>>>> Hi Jerry,
>>>> 
>>>> Again, I think not all the NSA should support https, but only
>>>> aggregaters are required to do so.
>>>> 
>>>> Considering the time we have before SC, making https madatory may have
>>>> too
>>>> much risk for success of SC demonstration.
>>>> 
>>>> Tomohiro
>>>> 
>>>> 
>>>> On Wed, 02 Nov 2011 00:12:44 -0400
>>>> Jerry Sobieski<jerry at nordu.net>  wrote:
>>>> 
>>>>> Hi all-
>>>>> 
>>>>> I just circulated the most recent global NSI topology for the
>>>>> Supercomputing demos.
>>>>> 
>>>>> It is now time to begin testing again.   Please get started asap, and
>>>>> monitor the nsi-wg chat room on Skype.
>>>>> 
>>>>> For those of you with uRA clients that do not perform any segmentation,
>>>>> please select an aggregator NSA and begin testing to that network NSA.
>>>>> 
>>>>> For the Aggregator NSAs, please verify that you are able to interop with
>>>>> each other implementation, then to each network.  start with your direct
>>>>> data plane neighbors and work your way outward.  (TK: do you have some
>>>>> thoughts on this verification process...?)
>>>>> 
>>>>> I think the key issues we need to work thru are a) HTTPS interop, b) SC
>>>>> WSDL consistency, c) Query result consistency, and then just
>>>>> coordination among the whole group so we do not get too many requests
>>>>> interfering with one another.   All NSI implementations should be able
>>>>> to successfully talk to all the other implementations by now with all
>>>>> primitives.
>>>>> 
>>>>> If we need additional VLANs, let me know and I can add more to the
>>>> 
>>>> topology.
>>>>> 
>>>>> We will want to develop a looping script at some point this week or
>>>>> early next.  This script will issues a sequence of Reservation Requests
>>>>> and walk the connection(s) through their lifecycle while the viz tools
>>>>> track the state transitions. _/This will be the fundamental demo during
>>>>> the conference.
>>>>> /_
>>>>> We probably need some simple orchestration tools:  An end system
>>>> 
>>>> daemon
>>>>> 
>>>>> that will configure an particular  IPaddr on the VLAN subinterface when
>>>>> a connection is provisioned and then issue/respond to pings.  Any idle
>>>>> hands out there want to work on some code?
>>>>> 
>>>>> Thanks!
>>>>> Jerry
>>> 
>> 
> 
>