So are you implying that the
<nsaAddress> is element is not just an opaque
reference, but an actual protocol address? Would this not
conflict with the requirement not to put any transport
implementation specific fields on the protocol?
I have defined the
<nsaAddress> element
as an anyURI because I anticipated you would be asking for
this as soon as you saw my example. If you want to model the
NSA address as a UDP port it can be done with the URI format
<nsaAddress>udp://NSA.NORDU.net:2764</nsaAddress> or
for TCP
<nsaAddress>tcp://NSA.NORDU.net:2764</nsaAddress> all
accomplished through the magic of the URI.
These are still protocol specific so you might want to
revert back to my nice abstract name :-)
As for not using STP in the <localId> of the STP...
I am not sure specifying a colon as an internal string
separator is a good idea when URI/URL are now becoming a de
facto standard for naming resources. Some of the
organizations that will participate in the NSI testbed use
this naming format already, and we should not force them to
change. I also do not think we should be specifying a
restricted character set for naming in the NSI with so many
standardized naming schemes available in RFCs.
Jerry... Come over to the dark side..
Which raises another question. Should naming support
multi-byte characters (UTF-8)?
John.
Oh...a couple other comments I forgot:
First, the <nsaAddresses> examples do not seem right...
The message should reference a RA NSA and a PA NSA... Those
should not need a domain reference...just the NSA identifier.
First, NSI context has no notion of a "domain"... but more
importantly, we need to specify where to find an NSA...it should
ultimately resolve to an IP address (v4 or v6) and a TCP port
that NSA is listening to. The NSA location can be specified in
a symbolic name manner, but it needs to be specific to the
transport layer it is using, and should not be handled
differently in the protocol for different transport layers.
So an NSA locator string could be: "NSA.NORDU.net:2764" meaning
the NSA is listening to port 2764 on the server
nsa.nordu.net. Or we could do "urn:ogf:network:
netherlight.edu" and assume it is using a default port that is
documented somewhere.
We need to come to closure on NSA resolution. I.e. How do we
specify an NSA location? Is it an IP address and TCP port? Is
it a standard DNS name? a URN of some sort?
Also, the string you referenced as a local part of the
netherlight.edu STP is probably not valid if we use the colon
seperated tuple for NSI endpoints. Endpoints will be
referenced outside of XML contexts. And endpoint strings will
be used in many other manners than simply the local NRM.
Therefore, I think it is imperative that we make sure the name
strings are as simple as possible. For instance is a network
name case sensitive? Can it have colons ":" embedded in it? Or
will that hose the tuple mechanism for naming? Are spaces
allowed? are linefeeds? Are contiguous spaces significant?
I was hoping we could let the local strings be whatever the
local NSA wants them to be, but I think we need to be a bit more
specific about how we expect to be able to use endpoint names.
We need to specify some constraints on the string values that
make up NSI names. I suggest case-insensitive, no spaces,
alphanumeric, and maybe a small set of special characters.
Jerry
Peoples,
I have attached an XML file that contains an example
reservation request message. Ignore the namespace information
and the schemaLocation statement as these would not be
included within the SOAP message.
John.