Hello, A long time ago we have had a discussion on naming, where we finalized on Nodes and Ports. However, due to feedback that I'm getting in projects where semantic network descriptions are now actually being used, I have received requests to change Port to Interface. The problem is that in these projects the network descriptions become part of a larger infrastructure. Having an object named Port there to describe a network connection point is confusing to users who are not network-centric. They think that a Port object would describe something like a TCP/UDP port, instead of a whole network interface. Would it be possible that NML also changes the Port object to Interface, so as to sync up with the schemas that are already in use in GENI, Geysers and NOVI? Jeroen.
Hi Jeroen, Good to see some usage feedback. I'd be interested in the schemata you are using.
Would it be possible that NML also changes the Port object to Interface, so as to sync up with the schemas that are already in use in GENI, Geysers and NOVI?
I have no personal preference.
They think that a Port object would describe something like a TCP/UDP port, instead of a whole network interface.
Just a minor remark: a Port in NML does not describe a whole network interface, but a logical network interface (which can either be a wavelength, an Ethernet port, but even a TCP/UDP port). I can imagine the confusion though. Freek
Hi Jeroen; On 8/26/11 7:47 AM, thus spake Jeroen van der Ham:
Hello,
A long time ago we have had a discussion on naming, where we finalized on Nodes and Ports. However, due to feedback that I'm getting in projects where semantic network descriptions are now actually being used, I have received requests to change Port to Interface.
Which projects, and when have you interacted with them or when have they approached you about this topic? You note 'requests' so please be specific if you could.
The problem is that in these projects the network descriptions become part of a larger infrastructure.
One could say that about just about any project looking to adopt the NML work, I don't believe these new groups are much different than anyone else in that regard.
Having an object named Port there to describe a network connection point is confusing to users who are not network-centric. They think that a Port object would describe something like a TCP/UDP port, instead of a whole network interface.
This sounds like a similar argument I can remember from 2007, when the founders of NML first got together to try to combine concepts from NDL/NM into something cohesive. My hazy memory seems to remember 'interface' and 'port' being on the table. At the time the group went with one ('port') since it was silly to endlessly debate on something like a name when there were other important things to deal with.
Would it be possible that NML also changes the Port object to Interface, so as to sync up with the schemas that are already in use in GENI, Geysers and NOVI?
You note a key problem in this request - "A long time ago we have had a discussion on naming". Lots of water has flowed under the bridge since that date, and products/software have latched on to these concepts over the span of years. Speaking selfishly only for things I care about (e.g. perfSONAR products and control frameworks such as OSCARS that have adopted 'in progress' versions of NML), I am not pleased to hear about this particular request given the amount of investment that has been made. Lots of interactions (protocol based and internal software management) have been structured around these concepts, and these products are deeply embedded and deployed in the infrastructure of many networks. I don't believe that this amount of investment should be forgotten as the group considers something as simple as a 'find/replace' in current documents. I personally would like to know more about these projects, and the reasons why they are approaching this working group (and by extension projects that have already started to implement NML concepts as is) with a request to go through a lot of work to re-introduce an old argument. I am all for collaboration, but it is not clear to me what benefits NML will receive as a tradeoff with these other projects. Thanks; -jason
Hello, On 30 Aug 2011, at 03:20, Jason Zurawski wrote:
Hi Jeroen;
On 8/26/11 7:47 AM, thus spake Jeroen van der Ham:
Hello,
A long time ago we have had a discussion on naming, where we finalized on Nodes and Ports. However, due to feedback that I'm getting in projects where semantic network descriptions are now actually being used, I have received requests to change Port to Interface.
Which projects, and when have you interacted with them or when have they approached you about this topic? You note 'requests' so please be specific if you could.
The projects in question are: - GEYSERS: EU project that we are also involved in, see http://geysers.eu - NOVI: EU project that we are involved in, see http://fp7-novi.eu - NDL-OWL: RENCI created an extension to NDL for the GENI context and has used also Interface there. - PlanetLab: also uses Node and Interface in their RSpec files.
The problem is that in these projects the network descriptions become part of a larger infrastructure.
One could say that about just about any project looking to adopt the NML work, I don't believe these new groups are much different than anyone else in that regard.
True. Traditionally our application area has been SURFnet, NetherLight and GLIF, which are very network-centric. For us it is a recent development that we look beyond the network and start applying semantic descriptions there.
Having an object named Port there to describe a network connection point is confusing to users who are not network-centric. They think that a Port object would describe something like a TCP/UDP port, instead of a whole network interface.
This sounds like a similar argument I can remember from 2007, when the founders of NML first got together to try to combine concepts from NDL/NM into something cohesive. My hazy memory seems to remember 'interface' and 'port' being on the table. At the time the group went with one ('port') since it was silly to endlessly debate on something like a name when there were other important things to deal with.
That's similar to how I remember it. It seems that now we do have an argument for Interface.
Would it be possible that NML also changes the Port object to Interface, so as to sync up with the schemas that are already in use in GENI, Geysers and NOVI?
You note a key problem in this request - "A long time ago we have had a discussion on naming". Lots of water has flowed under the bridge since that date, and products/software have latched on to these concepts over the span of years.
Speaking selfishly only for things I care about (e.g. perfSONAR products and control frameworks such as OSCARS that have adopted 'in progress' versions of NML), I am not pleased to hear about this particular request given the amount of investment that has been made. Lots of interactions (protocol based and internal software management) have been structured around these concepts, and these products are deeply embedded and deployed in the infrastructure of many networks. I don't believe that this amount of investment should be forgotten as the group considers something as simple as a 'find/replace' in current documents.
I personally would like to know more about these projects, and the reasons why they are approaching this working group (and by extension projects that have already started to implement NML concepts as is) with a request to go through a lot of work to re-introduce an old argument. I am all for collaboration, but it is not clear to me what benefits NML will receive as a tradeoff with these other projects.
The projects have used NML (and other ontologies) as a basis for semantic representations. We are involved in both GEYSERS and NOVI. We've used the Port object, and others in the project have requested that we use the Interface object. Other projects have already used the Node/Interface pair. To me personally it does not seem like a very strong argument that we should not change anything in NML, because people have started using it. NML is not finished yet, while we're in the final stages, there is still a possibility of change. To me, implementers take a risk in adopting NML. It seems though that more and more projects are going for "implementations" of NML, so perhaps we should start considering a "code freeze" soon. Jeroen.
On Aug 30, 2011, at 3:03 AM, Jeroen van der Ham wrote:
Hello,
On 30 Aug 2011, at 03:20, Jason Zurawski wrote:
Hi Jeroen;
On 8/26/11 7:47 AM, thus spake Jeroen van der Ham:
Hello,
A long time ago we have had a discussion on naming, where we finalized on Nodes and Ports. However, due to feedback that I'm getting in projects where semantic network descriptions are now actually being used, I have received requests to change Port to Interface.
Which projects, and when have you interacted with them or when have they approached you about this topic? You note 'requests' so please be specific if you could.
The projects in question are: - GEYSERS: EU project that we are also involved in, see http://geysers.eu - NOVI: EU project that we are involved in, see http://fp7-novi.eu - NDL-OWL: RENCI created an extension to NDL for the GENI context and has used also Interface there. - PlanetLab: also uses Node and Interface in their RSpec files.
The problem is that in these projects the network descriptions become part of a larger infrastructure.
One could say that about just about any project looking to adopt the NML work, I don't believe these new groups are much different than anyone else in that regard.
True. Traditionally our application area has been SURFnet, NetherLight and GLIF, which are very network-centric. For us it is a recent development that we look beyond the network and start applying semantic descriptions there.
Having an object named Port there to describe a network connection point is confusing to users who are not network-centric. They think that a Port object would describe something like a TCP/UDP port, instead of a whole network interface.
This sounds like a similar argument I can remember from 2007, when the founders of NML first got together to try to combine concepts from NDL/NM into something cohesive. My hazy memory seems to remember 'interface' and 'port' being on the table. At the time the group went with one ('port') since it was silly to endlessly debate on something like a name when there were other important things to deal with.
That's similar to how I remember it. It seems that now we do have an argument for Interface.
Would it be possible that NML also changes the Port object to Interface, so as to sync up with the schemas that are already in use in GENI, Geysers and NOVI?
You note a key problem in this request - "A long time ago we have had a discussion on naming". Lots of water has flowed under the bridge since that date, and products/software have latched on to these concepts over the span of years.
Speaking selfishly only for things I care about (e.g. perfSONAR products and control frameworks such as OSCARS that have adopted 'in progress' versions of NML), I am not pleased to hear about this particular request given the amount of investment that has been made. Lots of interactions (protocol based and internal software management) have been structured around these concepts, and these products are deeply embedded and deployed in the infrastructure of many networks. I don't believe that this amount of investment should be forgotten as the group considers something as simple as a 'find/replace' in current documents.
I personally would like to know more about these projects, and the reasons why they are approaching this working group (and by extension projects that have already started to implement NML concepts as is) with a request to go through a lot of work to re-introduce an old argument. I am all for collaboration, but it is not clear to me what benefits NML will receive as a tradeoff with these other projects.
The projects have used NML (and other ontologies) as a basis for semantic representations. We are involved in both GEYSERS and NOVI. We've used the Port object, and others in the project have requested that we use the Interface object. Other projects have already used the Node/Interface pair.
To me personally it does not seem like a very strong argument that we should not change anything in NML, because people have started using it. NML is not finished yet, while we're in the final stages, there is still a possibility of change. To me, implementers take a risk in adopting NML.
To me, personally, minor confusion does not seem like a very strong argument that we should make the change. The cost of switching is that people who have already adopted concepts are now out of luck. The cost of keeping it the same is some (possibly minor) confusion on the part of people looking to integrate NML concepts into their own stuff. Frankly, the former cost seems worse than the latter cost. Especially since there's going to be some confusion no matter what when folks who are not network-centric try to integrate the NML concepts, no matter what we name stuff. Once they see how stuff fits together, it should be easy to see what Port means in that context. Cheers, Aaron
It seems though that more and more projects are going for "implementations" of NML, so perhaps we should start considering a "code freeze" soon.
Jeroen. _______________________________________________ nml-wg mailing list nml-wg@ogf.org http://www.ogf.org/mailman/listinfo/nml-wg
Summer 2011 ESCC/Internet2 Joint Techs Hosted by the University of Alaska-Fairbanks http://events.internet2.edu/2011/jt-uaf
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.
On Aug 30, 2011, at 9:36 AM, Jeroen van der Ham wrote:
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.
Changing the name of one of the primary elements in NML 'Port' is a major overhaul.
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.
That's too bad. I think it would have been much better to use it so you could find out if there were any deficiencies and have real-world experience as to the issues we are discussing. If there were real problems that could not be addressed in a straight forward way, that is a reason to change the schema. The endless discussions of Port vs Interface that have gone on for 5 years now are just a distraction. I sometimes think we would have been better off to come up with completely bogus names for concepts. A 'Foo' is connected to a 'Bar'... would that have been better? jeff
Jeroen. _______________________________________________ nml-wg mailing list nml-wg@ogf.org http://www.ogf.org/mailman/listinfo/nml-wg
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.
Hello, On 30 Aug 2011, at 17:58, Jason Zurawski wrote:
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.
The reason that I am not using the NML namespace is because we're using a really simplified topology for the NSI plugfest. In the first instance there was even a suggestion to create some kind of NSI topology to use in the NSI demo that looked nothing like an NML topology. I've coaxed the participants to start using a simple kind of topology now, in the future we can start using NML more. One thing already came up, even with a simplified topology: NML misses the concept of labels. It has become apparent to me that an endpoint for a provisioned connection is not only a Port object, it is also the label that is associated with it, at that Port. Providers often also need to negotiate using a label on a connection. Jeroen.
Hi Jeroen/All; The rest of this conversations seems to have disappeared, are we done discussing the purpose of this thread? Will we need yet another subject change? Comments inline: On 8/31/11 5:04 AM, thus spake Jeroen van der Ham:
Hello,
On 30 Aug 2011, at 17:58, Jason Zurawski wrote:
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.
The reason that I am not using the NML namespace is because we're using a really simplified topology for the NSI plugfest. In the first instance there was even a suggestion to create some kind of NSI topology to use in the NSI demo that looked nothing like an NML topology.
I've coaxed the participants to start using a simple kind of topology now, in the future we can start using NML more.
If you believe this to be the right way forward, I suppose there is not a lot that can be done to change things at this point. This still does not sound like the best idea to me, because I have a little experience in the area of ideas being 'impacted' into code. Taking "no action" is a stronger force than taking action, and it seems to me that once there is a working implementation using this fake/minimal topology, there will not be a lot of momentum to change things that are in place and working. My $0.02 (or 0.013 Euro). Thanks; -jason
One thing already came up, even with a simplified topology: NML misses the concept of labels. It has become apparent to me that an endpoint for a provisioned connection is not only a Port object, it is also the label that is associated with it, at that Port. Providers often also need to negotiate using a label on a connection.
Jeroen.
Hi, On 31 Aug 2011, at 12:25, Jason Zurawski wrote:
Hi Jeroen/All;
The rest of this conversations seems to have disappeared, are we done discussing the purpose of this thread? Will we need yet another subject change?
I think we're about done with the discussion, to summarize: - I proposed to change Port to Interface to avoid possible confusion for users - Jeff feels a name change is a major overhaul (I wonder what impact a change on relations would be then). - Jason raises the point: what's in it for NML to change this? Other than avoiding confusion and adoption of Interface in several major projects, I can't think of any more arguments for the change. I think those projects will probably define something like "Interface owl:sameAs nml:Port" in their ontologies.
Comments inline:
On 8/31/11 5:04 AM, thus spake Jeroen van der Ham:
Hello,
On 30 Aug 2011, at 17:58, Jason Zurawski wrote:
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.
The reason that I am not using the NML namespace is because we're using a really simplified topology for the NSI plugfest. In the first instance there was even a suggestion to create some kind of NSI topology to use in the NSI demo that looked nothing like an NML topology.
I've coaxed the participants to start using a simple kind of topology now, in the future we can start using NML more.
If you believe this to be the right way forward, I suppose there is not a lot that can be done to change things at this point. This still does not sound like the best idea to me, because I have a little experience in the area of ideas being 'impacted' into code. Taking "no action" is a stronger force than taking action, and it seems to me that once there is a working implementation using this fake/minimal topology, there will not be a lot of momentum to change things that are in place and working.
The current focus of this plugfest is to get NSI implementations of the protocol working as a first step. Getting them to use any kind of topology is already a bonus. My plan is to step this up and get them to use a more serious topology description after GLIF. Jeroen.
W dniu 2011-08-30 17:58, Jason Zurawski pisze:
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.
One comment based on my experience from the work on circuit monitoring: it would have been easier and faster to use already existing and stable perfsonar NM schema (with possible small extensions) for topology description but it was decided to switch to NML. It wasn't smooth as required a lot of discussions but the final result is good so I'm happy we did this way. I would suggest the same approach for the NSI topology stuff. Cheers, Roman
participants (6)
-
Aaron Brown -
Freek Dijkstra -
Jason Zurawski -
Jeff W. Boote -
Jeroen van der Ham -
Roman Łapacz