[Nsi-wg] NSI Issues list – Rio de Janeiro Demo

[Jerry Sobieski]

Hi all-

I am glad to hear folks have been keeping notes about issues relating to 
the spec, and I am equally happy folks want to dive into and resolve 
these issues.   However,  I would ask everyone to remember that this is 
a *standards* effort, a group effort.   Not a attempt to simply solve a 
problem.   By this I mean that we are trying to find *CONSENSUS* in how 
and why we do anything/everything within these standards.    This means 
that we should bring *ALL* of these issues discovered in the demo rush 
to the working group for discussion and resolution - these are not 
issues that can be solved by anyone's individual initiative.

It is important that everyone understands that if you try to solve these 
issues unilaterally, you keep everyone one else from contributing to and 
thereby buying into the solution.  Even an easy solution or what you 
think is the obvious solution is not necessarily the proper solution.  
It is important that we discuss these issues in the working group forum 
_/and agree/_ to a solution.  Then we put it in the standard, and then 
we implement what is in the standard.

If you have ideas for how some of these issues should be solved, post it 
to the list first for discussion, or make a PPT and ask for time on a 
call.   Share your ideas with the group first, and be prepared to defend 
them and compromise when necessary.   This is how we build consensus 
*and* good code.

Thanks!
Jerry

On 9/14/11 10:46 AM, John MacAuley wrote:
> Peoples,
>
> Here are some of the notes I captured.
>
> The reservation XML message contains two element tags both named “reservation”.  The first is the reservation operation and the second is the reservation information contents.  This will need to be fixed in the types XSD.
>
> The “providerNSA” and “requesterNSA” elements in the NSI protocol header caused some confusion.  In the CS document we stated that this would be populated with the NSnetwork URN as defined in Salt Lake City. However, when the demo topology schema was created we introduced a new NSA object.  Some people used the URN of the NSA object in the  “providerNSA” and “requesterNSA” elements.  We will need to make a definitive statement as we define the formal NSI topology.  Do we rename the elements to “providerNSnetwork” and “requesterNSnetwork” and continue using the NSnetwork URNs, or do we switch over to NSA URN?
>
> Demo topology definition was an issue, but in the end we had something workable for the demo.  Going forward we need to formalize NSI topology definition and how it relates to other schema such as DTOX and NML.  I am going to start working on the topology discovery/exchange problem to get use moving forward.
>
> Security presented interoperability issues as some people enforced authentication and authorization while others did not.  Some systems could not provide the needed credentials, and resulted in some incompatibility.  I believe we are clear on what we want to implement for NSA-to-NSA security, but we need to formalize the session security requirements so we can begin to implement in the NSAs.
>
> Namespace issues – this is not an issue with the protocol specification but with a few of the less mature SOAP web services toolkits.  They get confused between the interface and type namespaces for the protocol elements due to the use of “ref” to reference protocol operation elements from the types XSD in the interfaces WSDL.
>
> Now that we have had some demo experience with error handling, I think it is time to start formalizing values in the NsiExceptionType.  I have already identified ten generic error conditions, and I am sure there are many more.  As a follow up to this item, NSA implementations need to populate the NsiExceptionType.variables with additional information to help identify the problem that caused the rejection of the message.  I had done this in OpenDRAC so any errors returned to other NSA would contain information formatted as follows:
>
>      <messageId>SVC0001</messageId>
>      <text>Invalid or missing parameter</text>
>      <variables>
>          <Attribute Name="replyTo" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
>              <AttributeValue xsi:type="xs:string" xmlns:xs="http://www.w3.org/2001/XMLSchema"
>                  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>                  >&lt;null&gt;</AttributeValue>
>          </Attribute>
>      </variables>
>
> Interface version discovery – I had discussed this with the group previously, but now that we are moving forward, up issuing NSI schema versions, and adding new interfaces we will need a mechanism for discovering the interfaces and versions supported by an NSA.  I will propose something formal when I get a chance.
>
> John.
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110914/7f88111e/attachment.html