Hi all, My apologies for the (very) late reply. I have a few generic comments and questions on "Extensible Protocol for NMC" for now and will follow up with some more detailed remarks later. (I planned to have the detailed remarks now, but was not able to finish reading all I wanted). My main point of criticism is that I do not (yet) understand why this protocol was developed; as a naive reader it seems to highly overlap with what has been done with WSDL. Unfortunately, I'm not an expert on either, so I might miss the point. WSDL was developed as a generic request-response protocol framework, and so is "Extensible Protocol for NMC". I still like the work, for example the idea on metadata is good. I just recommend to (a) build more on existing frameworks (e.g. specify that the protocol MUST use webservices instead of SHOULD, and refer to WS-whatever for authentication extension) and (b) make it more clear what was added. While I'm not very familiar with RELAX-NG, I think it is a good way forward, as it can be translated to XSD, and hopefully, this means there can be automated syntax check for messages. Has this been done so far? Last, the wording could be better in some places, especially when it comes to the RFC 2119 words (MUST, SHOULD, MAY). Two examples: "MAY or MAY NOT" (page 6), and my favourite: "Data MUST contain information, especially if it was empty in the initial request". Beside the obviousness of this statement (what else then information?) and the unclarity where "it" refers to, it seems that "SHOULD" was intended here, not MUST (why else the "especially"?). Summarizing: - The ideas are good - It should build more on WS-stuff (especially since this is the OGF, which is quite WS-frantic if you aks me). - The wording could be more strict. I hope to have more detailed replies while I finished the reference document, and read a bit on WSDL. (the awful truth is that I have not programmed a webservice yet). Regards, Freek
Hi Freek;
My main point of criticism is that I do not (yet) understand why this protocol was developed; as a naive reader it seems to highly overlap with what has been done with WSDL. Unfortunately, I'm not an expert on either, so I might miss the point. WSDL was developed as a generic request-response protocol framework, and so is "Extensible Protocol for NMC".
I still like the work, for example the idea on metadata is good. I just recommend to (a) build more on existing frameworks (e.g. specify that the protocol MUST use webservices instead of SHOULD, and refer to WS-whatever for authentication extension) and (b) make it more clear what was added.
Thank you for these comments, I will record them on the TODO lists. Regarding the issue of 'why nmc' instead of something like WSDL, the idea was sprung from the original use case of encoding measurements. The rationale at the time was if we were using an encoding scheme for the measurements, wrapping a similarly constructed control structure around each for communication was not a far stretch and may even make the job of parsing and interpreting the information easier.
While I'm not very familiar with RELAX-NG, I think it is a good way forward, as it can be translated to XSD, and hopefully, this means there can be automated syntax check for messages. Has this been done so far?
In practice services don't implement a strict schema check since it can be expensive, but the tools exist for both major implementations to do this.
Last, the wording could be better in some places, especially when it comes to the RFC 2119 words (MUST, SHOULD, MAY). Two examples: "MAY or MAY NOT" (page 6), and my favourite: "Data MUST contain information, especially if it was empty in the initial request". Beside the obviousness of this statement (what else then information?) and the unclarity where "it" refers to, it seems that "SHOULD" was intended here, not MUST (why else the "especially"?).
It would be very helpful if you could go through and correct these mistakes as you see them - particularly since you have experience in writing documents of this nature. May I mark you down as willing to do this task? Thanks; -jason
Hi Jason, Thanks a lot for your feedback. I really feel like a novice when it comes to monitoring (coming from path finding...), but I very much enjoy the discussion. Thanks! you wrote:
Regarding the issue of 'why nmc' instead of something like WSDL, the idea was sprung from the original use case of encoding measurements. The rationale at the time was if we were using an encoding scheme for the measurements, wrapping a similarly constructed control structure around each for communication was not a far stretch and may even make the job of parsing and interpreting the information easier.
As I said, I think the ideas are good. You mention "at the time". Would you do it differently if you were to redesign the schema? Perhaps my actual question is: does this doc describe the current practice as it has been done so far or is it an attempt to combine all good ideas into the best standard possible? If it is describing the current practice, would it be useful to improve it, or would that require too much rewriting for application developers?
[...] automated syntax check for messages. Has this been done so far?
In practice services don't implement a strict schema check since it can be expensive, but the tools exist for both major implementations to do this.
Message validity checking was one thing advocated by someone from UNINETT (The Norwegian NREN). I think it was either Arne Øslebø or Jon Hellan. Perhaps Roman remembers who it was. We could ask them exactly why they thought that to be useful.
Last, the wording could be better in some places, especially when it comes to the RFC 2119 words (MUST, SHOULD, MAY). [...]
It would be very helpful if you could go through and correct these mistakes as you see them - particularly since you have experience in writing documents of this nature. May I mark you down as willing to do this task?
You just did ;-) Regards, Freek
Hi Freek, All;
Regarding the issue of 'why nmc' instead of something like WSDL, the idea was sprung from the original use case of encoding measurements. The rationale at the time was if we were using an encoding scheme for the measurements, wrapping a similarly constructed control structure around each for communication was not a far stretch and may even make the job of parsing and interpreting the information easier.
As I said, I think the ideas are good. You mention "at the time". Would you do it differently if you were to redesign the schema? Perhaps my actual question is: does this doc describe the current practice as it has been done so far or is it an attempt to combine all good ideas into the best standard possible? If it is describing the current practice, would it be useful to improve it, or would that require too much rewriting for application developers?
According to the NMC charter:
The purpose of the Network Measurement and Control Working Group is to standardize the XML-based protocols that are currently in use in the perfSONAR project to control network measurement infrastructure and to share the results of the measurements and metrics that are generated.
As such we should be describing the current generation of communication protocols for perfSONAR varients. I would anticipate that minor changes may be required, for example Roman's suggestion that we avoid talking about a specific portion of the existing protocol, 'supportedEventType', comes from a short lived implementation hack (short lived = going on 2 years :)) that we do not wish to place into a protocol discussion. I don't view this group as a way to combine all the 'good' ideas because most ideas have been implemented and are in practice for many years now. If switching to WSDL was viable or popular, it would have happened already.
[...] automated syntax check for messages. Has this been done so far?
In practice services don't implement a strict schema check since it can be expensive, but the tools exist for both major implementations to do this.
Message validity checking was one thing advocated by someone from UNINETT (The Norwegian NREN). I think it was either Arne Øslebø or Jon Hellan. Perhaps Roman remembers who it was. We could ask them exactly why they thought that to be useful.
I believe validity checking is useful in cases where active development is taking place (e.g. reverse engineering what is and is not possible) as well as if you are not using an API to talk to services directly. Otherwise it seems like a waste of cycles (to me) to constantly check messages that are probably very similar. Regardless, this is more of a implementation issue and doesn't seem directly related to protocol development.
Last, the wording could be better in some places, especially when it comes to the RFC 2119 words (MUST, SHOULD, MAY). [...]
It would be very helpful if you could go through and correct these mistakes as you see them - particularly since you have experience in writing documents of this nature. May I mark you down as willing to do this task?
You just did ;-)
I have marked you down on the TODO list. -jason
Freek Dijkstra wrote:
Hi all,
My apologies for the (very) late reply.
I have a few generic comments and questions on "Extensible Protocol for NMC" for now and will follow up with some more detailed remarks later. (I planned to have the detailed remarks now, but was not able to finish reading all I wanted).
My main point of criticism is that I do not (yet) understand why this protocol was developed; as a naive reader it seems to highly overlap with what has been done with WSDL. Unfortunately, I'm not an expert on either, so I might miss the point. WSDL was developed as a generic request-response protocol framework, and so is "Extensible Protocol for NMC".
NMC schema transformed from Relax NG into XSD format could be used in WSDL file to describe all messages. I didn't try it but basing on my (limited) knowledge of WSDL it's possible. So I don't see the conflict here. I understand that WSDL was mentioned here as an example for general observation that maybe some existing standard could be used instead of NMC. The same comment was raised in Geant3 by people who were not involved earlier in pS work. The investigation of Netconf in pS is a try to look at this issue and find answers. Roman
Roman Lapacz wrote:
Freek Dijkstra wrote:
Hi all,
My apologies for the (very) late reply.
I have a few generic comments and questions on "Extensible Protocol for NMC" for now and will follow up with some more detailed remarks later. (I planned to have the detailed remarks now, but was not able to finish reading all I wanted).
My main point of criticism is that I do not (yet) understand why this protocol was developed; as a naive reader it seems to highly overlap with what has been done with WSDL. Unfortunately, I'm not an expert on either, so I might miss the point. WSDL was developed as a generic request-response protocol framework, and so is "Extensible Protocol for NMC".
NMC schema transformed from Relax NG into XSD format could be used in WSDL file to describe all messages. I didn't try it but basing on my (limited) knowledge of WSDL it's possible. So I don't see the conflict here.
I understand that WSDL was mentioned here as an example for general observation that maybe some existing standard could be used instead of NMC. The same comment was raised in Geant3 by people who were not involved earlier in pS work. The investigation of Netconf in pS is a try to look at this issue and find answers.
WSDL alone is not sufficient for defining working web services, one needs to define namespaces and XML schema, specific for the domain (NMC schema for network monitoring in our case). On the other hand, WSDL can still be used in implementations , together with NMC schema, to allow automatic generation of client classes, but this opportunity has not been explored so far. Best regards, Nina
Roman
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
Hello all, Are you sure Nina? Afaik a WSDL can be defined with a single method that takes a document and define that the document needs to have a NMWG schema? Alike: http://www.w3.org/2001/04/wsws-proceedings/uche/wsdl.html Though it does require a xsd or other supported schema type (eg not relaxng). Now relaxng can be transformed but the transformation isn't formal/unambiguous/two-way, or differently put if you transform from relaxng to xsd and back you are not guaranteed to end up with the same relaxng document. This is because some relaxng concepts can't be mapped completely into xsd. Now afaik we don't make use of such concepts now but it could create problems in the future. As I frequently hear that there is no objection to particular preference for xsd/relaxng from a theoretical standpoint (I know WG prefers relaxng) Why not switch to xsd for practial reasons? Considering I haven't seen the detailed report yet, please review the following comments with that in mind; For all that is wrong about perfsonar(and there are things wrong), certain key area's seem to be overlooked. Perfsonar is about sharing data to solve problems around services that stretch across multiple administrative domains as opposed to making the data available just within your own domain. For example AA, as far as Authentication is concerned with NETCONF; it is left to the transport layer which basically means that it's up to administrator/deployers to sort it out. Now I'm sure admins/deployers are up to the task but still it would require considerable effort as well as additional specification/conventions. As perfsonar is actually focused on making network measurements avail across multiple administrative domains it actually does solve/handle this. Even currently all it takes is to point a service to an AA-server. As pointed out on the perfsonar-dev list even suppling an AA-server could easily be done automatically. Perfsonar was not designed to replace current measurement systems the idea was to complement them. As such it shouldn't be competing with netconf; however as there are propriatary solutions for 'local' use. Netconf might find itself caught in the middle. Regards, Michael Nina Jeliazkova wrote:
Roman Lapacz wrote:
Freek Dijkstra wrote:
Hi all,
My apologies for the (very) late reply.
I have a few generic comments and questions on "Extensible Protocol for NMC" for now and will follow up with some more detailed remarks later. (I planned to have the detailed remarks now, but was not able to finish reading all I wanted).
My main point of criticism is that I do not (yet) understand why this protocol was developed; as a naive reader it seems to highly overlap with what has been done with WSDL. Unfortunately, I'm not an expert on either, so I might miss the point. WSDL was developed as a generic request-response protocol framework, and so is "Extensible Protocol for NMC".
NMC schema transformed from Relax NG into XSD format could be used in WSDL file to describe all messages. I didn't try it but basing on my (limited) knowledge of WSDL it's possible. So I don't see the conflict here.
I understand that WSDL was mentioned here as an example for general observation that maybe some existing standard could be used instead of NMC. The same comment was raised in Geant3 by people who were not involved earlier in pS work. The investigation of Netconf in pS is a try to look at this issue and find answers.
WSDL alone is not sufficient for defining working web services, one needs to define namespaces and XML schema, specific for the domain (NMC schema for network monitoring in our case).
On the other hand, WSDL can still be used in implementations , together with NMC schema, to allow automatic generation of client classes, but this opportunity has not been explored so far.
Best regards, Nina
Roman
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
------------------------------------------------------------------------
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
Wiadomość napisana w dniu 2010-01-20, o godz. 19:28, przez Michael Bischoff:
Hello all,
Are you sure Nina? Afaik a WSDL can be defined with a single method that takes a document and define that the document needs to have a NMWG schema?
Alike: http://www.w3.org/2001/04/wsws-proceedings/uche/wsdl.html
Though it does require a xsd or other supported schema type (eg not relaxng). Now relaxng can be transformed but the transformation isn't formal/unambiguous/two-way, or differently put if you transform from relaxng to xsd and back you are not guaranteed to end up with the same relaxng document. This is because some relaxng concepts can't be mapped completely into xsd. Now afaik we don't make use of such concepts now but it could create problems in the future.
As I frequently hear that there is no objection to particular preference for xsd/relaxng from a theoretical standpoint (I know WG prefers relaxng) Why not switch to xsd for practial reasons?
Hmm, it's not a bad idea to switch from relaxng to xsd in nmc documents (although I like more the former). Most documentations of xml schemas I've seen were done with xsd. Roman
Hi all, On Jan 20, 2010, at 8:05 PM, Roman Lapacz wrote:
Wiadomość napisana w dniu 2010-01-20, o godz. 19:28, przez Michael Bischoff:
Hello all,
Are you sure Nina? Afaik a WSDL can be defined with a single method that takes a document and define that the document needs to have a NMWG schema?
Alike: http://www.w3.org/2001/04/wsws-proceedings/uche/wsdl.html
Though it does require a xsd or other supported schema type (eg not relaxng). Now relaxng can be transformed but the transformation isn't formal/unambiguous/two-way, or differently put if you transform from relaxng to xsd and back you are not guaranteed to end up with the same relaxng document. This is because some relaxng concepts can't be mapped completely into xsd. Now afaik we don't make use of such concepts now but it could create problems in the future.
As I frequently hear that there is no objection to particular preference for xsd/relaxng from a theoretical standpoint (I know WG prefers relaxng) Why not switch to xsd for practial reasons?
Hmm, it's not a bad idea to switch from relaxng to xsd in nmc documents (although I like more the former). Most documentations of xml schemas I've seen were done with xsd.
I'm not an expert in relaxng... so, is it more powerful than xsd? Sorry about that "stupid" question... maybe it's like discussing if you should install Debian or Ubuntu... :-D Regards
Roman
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
-- Cándido Rodríguez Montes E-mail: candido.rodriguez@rediris.es Middleware warrior Tel:+34 955 05 66 13 Red.ES/RedIRIS Edificio CICA Avenida Reina Mercedes, s/n 41012 Sevilla SPAIN
Candido Rodriguez Montes wrote:
Hi all,
On Jan 20, 2010, at 8:05 PM, Roman Lapacz wrote:
Wiadomość napisana w dniu 2010-01-20, o godz. 19:28, przez Michael Bischoff:
Hello all,
Are you sure Nina? Afaik a WSDL can be defined with a single method that takes a document and define that the document needs to have a NMWG schema?
Alike: http://www.w3.org/2001/04/wsws-proceedings/uche/wsdl.html
Though it does require a xsd or other supported schema type (eg not relaxng). Now relaxng can be transformed but the transformation isn't formal/unambiguous/two-way, or differently put if you transform from relaxng to xsd and back you are not guaranteed to end up with the same relaxng document. This is because some relaxng concepts can't be mapped completely into xsd. Now afaik we don't make use of such concepts now but it could create problems in the future.
As I frequently hear that there is no objection to particular preference for xsd/relaxng from a theoretical standpoint (I know WG prefers relaxng) Why not switch to xsd for practial reasons?
Hmm, it's not a bad idea to switch from relaxng to xsd in nmc documents (although I like more the former). Most documentations of xml schemas I've seen were done with xsd.
I'm not an expert in relaxng... so, is it more powerful than xsd? Sorry about that "stupid" question... maybe it's like discussing if you should install Debian or Ubuntu... :-D
For me relaxng is more readable than xsd. Roman
Hello all,
Are you sure Nina? Afaik a WSDL can be defined with a single method that takes a document and define that the document needs to have a NMWG schema?
Alike: http://www.w3.org/2001/04/wsws-proceedings/uche/wsdl.html
Though it does require a xsd or other supported schema type (eg not relaxng). Now relaxng can be transformed but the transformation isn't formal/unambiguous/two-way, or differently put if you transform from relaxng to xsd and back you are not guaranteed to end up with the same relaxng document. This is because some relaxng concepts can't be mapped completely into xsd. Now afaik we don't make use of such concepts now but it could create problems in the future.
As I frequently hear that there is no objection to particular preference for xsd/relaxng from a theoretical standpoint (I know WG prefers relaxng) Why not switch to xsd for practial reasons?
Hmm, it's not a bad idea to switch from relaxng to xsd in nmc documents (although I like more the former). Most documentations of xml schemas I've seen were done with xsd.
I'm not an expert in relaxng... so, is it more powerful than xsd? Sorry about that "stupid" question... maybe it's like discussing if you should install Debian or Ubuntu... :-D
For me relaxng is more readable than xsd.
I don't feel strongly about this for either case. We can add the XSD representation to the Apendix and show both if there is interest, or we can go with just one. I would prefer to stick with RELAX since this represents the physical work we did (not a mechanical translation). -jason
Roman Lapacz wrote:
For me relaxng is more readable than xsd.
Jason Zurawski wrote:
We can add the XSD representation to the Apendix and show both if there is interest, or we can go with just one. I would prefer to stick with RELAX since this represents the physical work we did.
I agree with Roman, and propose not to include the XSD in the documents. As long as no WSDL is used, there is no benefit in adding that. Michael Bischoff also wrote:
Now relaxng can be transformed but the transformation isn't formal/unambiguous/two-way, or differently put if you transform from relaxng to xsd and back you are not guaranteed to end up with the same relaxng document.
I was not aware of this. I thought the RELAXNG -> XSD translation was unambiguous. In case someone later wants to add XSD, perhaps it is useful to note this differences and perhaps even suggest how the translation should be done. Regards, Freek
Now relaxng can be transformed but the transformation isn't formal/unambiguous/two-way, or differently put if you transform from relaxng to xsd and back you are not guaranteed to end up with the same relaxng document.
I was not aware of this. I thought the RELAXNG -> XSD translation was unambiguous.
In case someone later wants to add XSD, perhaps it is useful to note this differences and perhaps even suggest how the translation should be done.
There are specific cases where the translation program that we were using at the time (Sun's MSV - I thought development stopped in 2007 but I now see some updates: https://msv.dev.java.net/) could not handle conversion properly. Specifically it is possible in RELAX to construct an 'or' type relationship between an attribute and a child element, ex: <parent type="something" /> vs <parent> <type>something</type> </parent> The subsequent XSD document produced by conversion was ambiguous to most syntax checkers, but a manual change made the syntax/structure made things correct and unambiguous. This is a tool problem, not a language problem. As for a conversion back to RELAX, I have never attempted to do this so Michael is probably more experienced in this area than I am. -jason
On Jan 21, 2010, at 5:36 AM, Jason Zurawski wrote:
There are specific cases where the translation program that we were using at the time (Sun's MSV - I thought development stopped in 2007 but I now see some updates: https://msv.dev.java.net/) could not handle conversion properly. Specifically it is possible in RELAX to construct an 'or' type relationship between an attribute and a child element, ex:
<parent type="something" />
vs
<parent> <type>something</type> </parent>
Side comment... This is a perfect example of the kind of thing *I think* we should be trying to clean up and remove from the 'standardized' version of the protocol. (It is fine to be very general in a schema and during prototyping when you are not sure what you need - once we encode it into a standardized protocol message, we should reduce the number of ways the information can be rendered so clients can be more simple.) jeff
Jason Zurawski wrote:
As I frequently hear that there is no objection to particular preference for xsd/relaxng from a theoretical standpoint (I know WG prefers relaxng) Why not switch to xsd for practial reasons?
Hmm, it's not a bad idea to switch from relaxng to xsd in nmc documents (although I like more the former). Most documentations of xml schemas I've seen were done with xsd.
I'm not an expert in relaxng... so, is it more powerful than xsd? Sorry about that "stupid" question... maybe it's like discussing if you should install Debian or Ubuntu... :-D
For me relaxng is more readable than xsd.
I don't feel strongly about this for either case. We can add the XSD representation to the Apendix and show both if there is interest, or we can go with just one.
Definitely one. I prefer relaxng but the doc is not for me but for all who would like to get to know the protocol. If we see that much more people around us are familiar with xsd then this should be chosen. Comments from all NMC participants and their observations are welcome. Roman
I would prefer to stick with RELAX since this represents the physical work we did (not a mechanical translation).
-jason _______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
Michael Bischoff wrote:
Hello all,
Are you sure Nina? Afaik a WSDL can be defined with a single method that takes a document and define that the document needs to have a NMWG schema?
Yes indeed. Sorry for not being clear, I wanted to point domain specific schema is necessary anyway. Best regards, Nina
Alike: http://www.w3.org/2001/04/wsws-proceedings/uche/wsdl.html
Though it does require a xsd or other supported schema type (eg not relaxng). Now relaxng can be transformed but the transformation isn't formal/unambiguous/two-way, or differently put if you transform from relaxng to xsd and back you are not guaranteed to end up with the same relaxng document. This is because some relaxng concepts can't be mapped completely into xsd. Now afaik we don't make use of such concepts now but it could create problems in the future.
As I frequently hear that there is no objection to particular preference for xsd/relaxng from a theoretical standpoint (I know WG prefers relaxng) Why not switch to xsd for practial reasons?
Considering I haven't seen the detailed report yet, please review the following comments with that in mind;
For all that is wrong about perfsonar(and there are things wrong), certain key area's seem to be overlooked.
Perfsonar is about sharing data to solve problems around services that stretch across multiple administrative domains as opposed to making the data available just within your own domain. For example AA, as far as Authentication is concerned with NETCONF; it is left to the transport layer which basically means that it's up to administrator/deployers to sort it out. Now I'm sure admins/deployers are up to the task but still it would require considerable effort as well as additional specification/conventions. As perfsonar is actually focused on making network measurements avail across multiple administrative domains it actually does solve/handle this. Even currently all it takes is to point a service to an AA-server. As pointed out on the perfsonar-dev list even suppling an AA-server could easily be done automatically.
Perfsonar was not designed to replace current measurement systems the idea was to complement them. As such it shouldn't be competing with netconf; however as there are propriatary solutions for 'local' use. Netconf might find itself caught in the middle.
Regards,
Michael
Nina Jeliazkova wrote:
Roman Lapacz wrote:
Freek Dijkstra wrote:
Hi all,
My apologies for the (very) late reply.
I have a few generic comments and questions on "Extensible Protocol for NMC" for now and will follow up with some more detailed remarks later. (I planned to have the detailed remarks now, but was not able to finish reading all I wanted).
My main point of criticism is that I do not (yet) understand why this protocol was developed; as a naive reader it seems to highly overlap with what has been done with WSDL. Unfortunately, I'm not an expert on either, so I might miss the point. WSDL was developed as a generic request-response protocol framework, and so is "Extensible Protocol for NMC".
NMC schema transformed from Relax NG into XSD format could be used in WSDL file to describe all messages. I didn't try it but basing on my (limited) knowledge of WSDL it's possible. So I don't see the conflict here.
I understand that WSDL was mentioned here as an example for general observation that maybe some existing standard could be used instead of NMC. The same comment was raised in Geant3 by people who were not involved earlier in pS work. The investigation of Netconf in pS is a try to look at this issue and find answers.
WSDL alone is not sufficient for defining working web services, one needs to define namespaces and XML schema, specific for the domain (NMC schema for network monitoring in our case). On the other hand, WSDL can still be used in implementations , together with NMC schema, to allow automatic generation of client classes, but this opportunity has not been explored so far.
Best regards, Nina
Roman
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
------------------------------------------------------------------------
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
participants (7)
-
Candido Rodriguez Montes -
Freek Dijkstra -
Jason Zurawski -
Jeff W.Boote -
Michael Bischoff -
Nina Jeliazkova -
Roman Lapacz