Hi Freek,
Nice document!
FWIW, the draft includes:
"Email: replogle(a)ogf.org [[Joel Replogle: Check if a generic mail
address exists]]"
I think 'editor(a)ogf.org' is a suitable generic address, which exists
and is currently forwarded to Joel and Greg Newby.
Cheers, Andre.
On Sat, Nov 13, 2010 at 11:19 PM, Freek Dijkstra <freek(a)macfreek.nl> wrote:
> All,
>
> I'm cross-posting this to NM, NMC and NML, who are currently using the
> urn:ogf:network syntax.
>
> This namespace is currently not formalized. To this end, 3 documents
> will be created:
> - an Internet-Draft with syntax description and delegation of urn:ogf
> - a GFD with procedural description for subdelegations in urn:ogf
> - a GFD with syntax and subdelegation of urn:ogf:network
>
> The first document has been created, and is available at
> http://tools.ietf.org/html/draft-dijkstra-urn-ogf
>
> You can leave feedback at
> https://forge.gridforum.org/sf/go/artf6459
>
> Or download the (XML) document source code at:
> https://forge.gridforum.org/sf/scm/do/listRepositories/projects.nml-wg/scm
>
> Regards,
> Freek Dijkstra
> _______________________________________________
> Nmc-wg mailing list
> Nmc-wg(a)ogf.org
> http://www.ogf.org/mailman/listinfo/nmc-wg
>
--
Nothing is ever easy...
All,
I'm cross-posting this to NM, NMC and NML, who are currently using the
urn:ogf:network syntax.
This namespace is currently not formalized. To this end, 3 documents
will be created:
- an Internet-Draft with syntax description and delegation of urn:ogf
- a GFD with procedural description for subdelegations in urn:ogf
- a GFD with syntax and subdelegation of urn:ogf:network
The first document has been created, and is available at
http://tools.ietf.org/html/draft-dijkstra-urn-ogf
You can leave feedback at
https://forge.gridforum.org/sf/go/artf6459
Or download the (XML) document source code at:
https://forge.gridforum.org/sf/scm/do/listRepositories/projects.nml-wg/scm
Regards,
Freek Dijkstra
(PS: sorry if you received this twice, I accidentally sent this from my
private mail address before.)
Hi all,
After writing our ideas on identifiers down, I still have a five smaller
questions.
Quotes are from the meeting notes
(http://forge.gridforum.org/sf/docman/do/downloadDocument/projects.nml-wg/do…)
> Rough consensus on:
> - http://schemas.ogf.org/nml/base/2013/10/ (Jason's proposal)
Question 1. Should the schema end with a / or #?
a) http://schemas.ogf.org/nml/base/2013/10 (common for XML)
b) http://schemas.ogf.org/nml/base/2013/10/ (current proposal)
c) http://schemas.ogf.org/nml/base/2013/10# (common for RDF)
For XML I don't think it makes any difference; for RDF, I think it
should be b or c. (We may decide on a different namespace for XML and
RDF, but I propose not to do that unless there are compelling reasons to
do so).
Further recap from the meeting notes:
> In Catania NML decided on Instance identifiers format: urn:ogf:network:<domain part>:<local part>
> <local> is opaque only processed by end parts
> GLIF also agreed to use this format.
>
> Richard & Freek did put together a doc for the IETF RFC to define the URI
> Freek has translated to xml but he needs to consult Joel on web site details
>
> Case insensitive:
> RFC says have to specify case sensitive/insensitive
> So need to define urn:ogf: at OGF level
> Then :network: and the rest case insensitive.
> i.e. have to define the lexical equivalence.
>
> Rough consensus on:
> - Different objects eg link and port MUST have different identifiers
> - instance identifiers are case insensitive
> - instance identifiers are non-international (thus an URI instead of IRI)
> - URI are not restricted by length, other than possible restrictions
> by RFC 2141 (the current GLIF recommendation is max 48 to 80 bytes)
I forgot to mention in the notes that we a discussion how to refer to
identifiers.
(see slides 14-18 in http://forge.gridforum.org/sf/go/doc16081)
- RDF uses the attributes rdf:about and rdf:resource
- NM-WG uses the attributes id and idref
- The BUILT-IN XML ID and IDREF attributes can not be used,
since they only work within a document.
We had a discussion if we should re-use the id and idref from the NM
working group (formally: re-use the attributes in the
http://ggf.org/ns/nmwg/base/2.0/ namespace) or are to redefine these
attributes again.
I forgot what the consensus was.
Question 2. What attributes to use for references in XML?
a) existing id and idref in NM-WG namespace
b) redefine id and idref in NML namespace
c) create dedicated namespace for just id and idref
We decided on the urn:ogf:network:example.net:opaque-identifier syntax.
We have not yet defined what characters should be allowed in the opaque
identifier part. We have the following options:
Allowed characters:
GLIF: A-Z a-z 0-9 - .
RFC2141: A-Z a-z 0-9 - . _ ( ) + , : = @ ; $ ! * ' %hex
pchar: A-Z a-z 0-9 - . _ ~ ( ) + , : = @ ; $ ! * ' & %hex
unreserved: A-Z a-z 0-9 - . _ ~
where %hex is a percentage-encoding. E.g. %2E.
- unreserved and pchar are definitions from RFC 3986, which defines URIs
- GLIF is what is defined in the GLIF working group. This is extremely
limited (: and _ are not allowed).
- RFC 2141 is what is currently allowed in a URN. (this list excludes 4
"reserved" characters which are in the definition for future use.)
- RFC 2141 is currently being revised. It is very likely that & and ~
will be allowed, making the definition equal to that of pchar.
- unreserved is similar to the current GLIF list.
- Note that the following characters are NEVER allowed:
% / ? # [ ] \ " < > [ ] ^ ` { | }
Question 3. What characters are allowed in <opaque string>?
a) GLIF: A-Z a-z 0-9 - .
b) unreserved: A-Z a-z 0-9 - . _ ~
c) RFC2141: A-Z a-z 0-9 - . _ ( ) + , : = @ ; $ ! * ' %hex
d) pchar: A-Z a-z 0-9 - . _ ~ ( ) + , : = @ ; $ ! * ' & %hex
The current schema states that ALL Network Objects MUST have an identifier.
This is very strict. For example, even a network object that is never
referenced MUST still have an ID. Thus the following is NOT allowed:
<nml:bidirectionallink id="urn:ogf:network:es.net:bilink_A-C">
<nml:link>
<nml:relation type="serialcompound">
<nml:link idRef="urn:ogf:network:es.net:link_A_to_B"/>
<nml:link idRef="urn:ogf:network:es.net:link_B_to_C"/>
</nml:relation>
</nml:link>
<nml:link>
<nml:relation type="serialcompound">
<nml:link idRef="urn:ogf:network:es.net:link_C_to_B"/>
<nml:link idRef="urn:ogf:network:es.net:link_B_to_A"/>
</nml:relation>
</nml:link>
</nml:bidirectional>
Instead, everything MUST be named, like so:
<nml:bidirectionallink id="urn:ogf:network:es.net:bilink_A-C">
<nml:link id="urn:ogf:network:es.net:link_A_to_C"> <!-- ADDED id -->
<nml:relation type="serialcompound">
<nml:link idRef="urn:ogf:network:es.net:link_A_to_B"/>
<nml:link idRef="urn:ogf:network:es.net:link_B_to_C"/>
</nml:relation>
</nml:link>
<nml:link id="urn:ogf:network:es.net:link_C_to_A"> <!-- ADDED id -->
<nml:relation type="serialcompound">
<nml:link idRef="urn:ogf:network:es.net:link_C_to_B"/>
<nml:link idRef="urn:ogf:network:es.net:link_B_to_A"/>
</nml:relation>
</nml:link>
</nml:bidirectional>
Question 4. MUST all object have an id?
a) All Network Objects MUST have an identifier.
a) All Network Objects SHOULD have an identifier.
"SHOULD" means that an identifier may be left out, but only if it is
clear what the consequences are (in this case: the result can not be
referred to.)
The current schema states that the Syntax of the identifier MUST follow
the urn:ogf:network syntax.
This might make future compatibility harder (e.g. when trying to combine
it with other protocols; I can imagine that in the future other naming
schema's may be developed).
Question 5. MUST urn:ogf:network syntax be used?
a) All identifiers MUST follow the urn:ogf:network syntax
b) All identifiers MUST be a URI, and SHOULD follow the urn:ogf:network
syntax
c) All identifiers MUST be a unique, and MAY follow the urn:ogf:network
syntax
(some more variants are possible)
Regards,
Freek
Attached are the meeting notes made in OGF30 in Brussels.
For slides and this form in ASCII, see
http://forge.gridforum.org/sf/docman/do/listDocuments/projects.nml-wg/docma…
Regards,
Freek
Rough Consensus
===============
* Namespace for schema (object and attribute identifiers) is
http://schemas.ogf.org/nml/base/2013/10/ (with year and month the date
of the actual schema)
* Instance identifiers SHOULD follow the
urn:ogf:network:domain.name:opaque_id syntax. These identifiers are case
insensitive, and non-international.
* Instance identifiers are not restricted in length, like GLIF requires.
* Different objects eg link and port MUST have different identifiers
* Everything is just a link – don’t need to distinguish between paths,
links and segments.
* "Group" is subclassed with "BidirectionalLink", "BidirectionalPort", etc.
* Allow grouping of 2 serial compounds links
* Disallow relating groups together until a clear use case and related
logic is presented.
* Adaptation relates ports, not links. This is still open for discussion.
* cross connects must be included in a serial compound link
* connectors (plastic) can be described as a port, without the need to
describe a cross connect
Action Items
============
* Revise definition of multiplexing: Freek, Jeroen
* Setup a teleconference: Jeroen
* Ask for whiteboard software (Adobe connect) for teleconference: Jason
* Specs for delegation of urn:ogf namespace: Freek, Richard, Joel Replogle
* Specs for urn:ogf:network identifiers: Freek
* Propose description of multicast and broadcast links: Richard, Freek
* Create example of adaptation on Port/Link: Jeroen, Jason
* Given example of serial compound links with and without cross connect:
Freek
* How to specify properties of relations: <question postponed>
* How to specify the order in relations: Jason (XML), Jeroen (RDF)
* Explain NSI requirements/solutions for channels and labels: Tomohiro
