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