[Nml-wg] Possibility of changes (was Re: Interface vs Port)

[Jason Zurawski]

Hi Jeroen/All;

A running implementation is not the only argument, its just one of the 
possible arguments.  perfSONAR/OSCARS/et al. knew they were adopting a 
living standard, and as such were aware of the risks in doing so.  This 
does not mean they don't get a say in questioning the motivation and 
implications of a working group decision to reverse course on a key 
concept, or being upset that it is being suggested.  As someone who has 
put in a lot of work in this area, I am a bit upset that 'outsiders' who 
have not been heavily invested in the process would think that this 
suggestion would not cause some headaches.

I still stand by my previous statement that wasn't really answered yet: 
what motivation do we as a working group have to change prior work? 
Beyond fostering some adoption, that I am convinced would happen 
regardless of this proposed name choice, I would like to know "what is 
in it for NML".  This is not a simple change for the working group or 
partnering organizations that are working to build real solutions in 
this space, and as such needs some serious rationale to be listed out.

Regarding plugfest, your statement surprises me.  This is an opportunity 
to show the work being produced by the NML working group as an 
interoperable and legitimate way to describe network topology.  Using 
something different, with no real ties to the working group, means that 
what is being produced really is "demo" code that will need to be 
'changed' when the final standard is produced.  This seems like a bit 
mistake, and a loss for the WG in my opinion.

Thanks;

-jason

On 8/30/11 11:36 AM, thus spake Jeroen van der Ham:
> Hello,
>
> Just out of curiosity, how much change is still acceptable for
> current implementations?
>
> We've had two discussions now where the argument has come up that
> there are currently implementations that do things a certain way, and
> that we therefore should be hesitant to change.
>
> Now I'm certainly not planning a major overhaul of NML, and things
> have been reasonably static for a while, but as far as I know we have
> not reached a status of complete agreement. To me, we're still in a
> status where implementations based on NML are taking a risk.
>
> For example, I'm currently working on an implementation of topologies
> cooperating with the NSI plugfest. This implementation is
> deliberately not using the NML namespace, because I don't want
> developers to feel that we've reached agreement yet. Things may still
> change, and if they would, it should not be a big deal to them.
>
> Jeroen.