Hi John-
On 4/11/11 9:58 PM, John MacAuley wrote:
Jerry,
Had a look at the XSD and have a few comments.
1. Run a spell checker over the comments. There are a few
spelling mistakes.
No doubt. How do I get Oxygen to create a .docx file for inclusion
in word? It spits out HTML or PDF or DOCBOOK format - none of which
are sutible for the word processor we use. Ugh.
2. "serviceNameType"
why restrict the length 4-32 of the name?
Why make it longer than it needs to be?
This is just a service name. Its as trng used for matching. It
differntiates two services. If you allow a name to be any length,
it becomes unwieldy and difficult to match on. The 4 character min
was just arbitrary - I hesitate to allow a service name to be "0"...
It should be at least a little bit descriptive.
As for maxlength=32, again arbitrary. But I do believe it should be
finite and only as long as neccesry to perform the function it is
meant to perform: identifying the service parameters associated with
the service.
Just because we can make it any length does not mean we should or
that doing so improves it.
3. "Orig"
STP is restricted to value="[a-zA-Z0-9$]+:[a-zA-Z0-9$]+".
It seems an arbitrary restriction, and restricts
implementations from having a proper URN for the endpoint
name as specified in NML and the GLIF. Can we please reduce
the restriction?
The value of the NSI Endpoint names is whatever the NSI specifies.
And I thought we had tentatively agreed that for NSI endpoint names,
the GLIF tuple was adequate. I put these characters in from memory
for what the GLIF global naming recommendation allowed. So there
may be some other characters missing, but colons are definitely not
allowed as they were explicitly used to separate the global portion
form the local portion.
Remember John: The syntax of Network names and Endpoint names are
not part significant in the NSI-CS application. The tuple is
significant. A name that is unecessarily complex will impede
adoption. These are names users apply to their interfaces, and what
they will use in their service requests. Why do these need to be
URNs? WhatURN would you specify they use? If you need this user
specified string to be part of a name space, can't you do that in
your code? What does the user get out of it? The user will provide
a name in the service request that represents his cluster or
server. How do they know what the URN designator will be or ought
to be? Why do you expect some biomedical researcher to name their
video system with a GLIF URN?
The naming works as it is. Why do you think it needs to be URNs?
4.
Same for the "Dest" STP.
5.
For "Bandwidth" there is
an upper limit of <xsd:maxInclusive value="1000"/> Mb/s
or 1 Gb/s. With 10GE in the network should we not
consider a higher limit?
Oops. My mistake. Indeed, perhaps we should bump this to 100
Gbps?
Just to argue :-) Actually, the service definition as stated is
fine. If some network has a 10 Gbps offering, or a 100 Gbps
offering, they can change this upper limit. They would still have a
conforming Service Definition. It would offer higher speeds, but it
would be the same essential service offering. (This is the beauty
of SDs...networks can adjust the parameters somewhat and still
interoperate. For instance, if we put the bandwith upper limit at
100Gbps, and no one had 100 Gbps, they would just independently drop
this to 10 Gbps or 1 Gbps and would also still conform.
6.
We have a "ScheduleStart" and a "ScheduleEnd" but we
have not specified a maximum duration.
I tried to figure out how to validate the schedule parameters using
the xsd. This is not easy since different cases are presented by
the relative time to the time when the request is received. E.g. a
Start time before "now" is not possible...so does it mean "asap"?
Is a start date of 0000/00/00 allowed?
So I put a very simple parameterization in for now. A valid
dateTime is required, but we leave it to the NSA to resolve what
time it is now, and same with the end time/duration... We could
allow a duration, but what does validating do for us? (I think
duration is useful, let me hit it again...)
Another useful feature of the SD: Since the Service itself is not
part of the standard it can be modified indepednetly of the
standard. A group of us could take this XSD and hammer a more
sophisticated service into it. One that has a maximum Duration
attribute. This does not prevent this basic SD from working.
Right? Sure, it may not be perfect, but the Service Definition can
be changed. Thats why in the name I included a Version x.x string
at the end - this can indicate which version of the service is being
processed or is desired.
You too!
J