Hi there, I will add my two cents, with the caveats that I'm not very directly involved in this work any more and I'm only on my first cup of coffee.
Endpoint = attribute value { xsd:string } & attribute type { "IPv4address" | "IPv6address" | "IPv4hostname" | "IPv6hostname } & attribute port { xsd:int }?
Address = xsd:string & attribute type { "IPv4" | "IPv6" }
I agree with both of you here, so why not make a specialized sub-schema for IP addresses? In a new namespace, perhaps "http://ns.ggf.org/nmwg/topo/ip/" or whatever the current incantation is. At the risk of being a strict constructionist, I suggest you could even have "../ip/4/" and "../ip/6/" sub-schemas to describe specifics of each protocol version. Either way, I think it's great if someone tries to sub-class all these things that are intended as general, as it is often the case that something too specific has crept in, like a thief in the night.
COMMENT #3 ---------- Just a question. I don't understand InterfaceContent in nmwgtopo.rnc
There is ipAddress and ifAddress. What is the difference? I guess ipAddress is the address used to reach the router while ifAddress is configured on the monitored interface? Maybe we should make that more explicit?
The ipAddress more or less the address of the chassis; it is an administrative address that may be running some form of management software. The ifAddress is the particular address of an interface. We have kept both as a courtesy to implementation designers; this may prevent a forced lookup of an address saving valuable time and effort.
huh? if it's the "administrative" address, you should call it that. But I don't see this as generally applicable. Let caching be handled by the implementation. I would think that what you need is the interface name/index and addresses. Given the note below, organized as a list of (address, interface name) pairs, where either or both can be repeated. Imitating the brilliant representation of traceroute :-) -Dan
COMMENT #4 ---------- Note an interface in IPv6 has by nature several IPv6 addresses. I mean unicast addresses here. There are link-local addresses (often only one derived from physical interface address) and one or more global unicast addresses. It is I think necessary that ifAddress in InterfaceContent of nmwgtopo.rnc becomes a vector instead of just a single element? I guess we should display as well the link-local address... maybe having some type for it like "IPv6-LL")
We have only briefly dealt with ipv6 issues in the schemas, and we do hope to encompass more features in the future. It is possible to have a 'list' element in a schema, although i am unsure of what ramifications (if any) it would bring to the current design. This is something we should consider.