Subject: Re: [I2G2-Proto] NMWG schema comments (mainly about IPv6 and multicast)
From: Jerome Durand <[email-masked]>
To: [email-masked]
Cc: Prototype-JRA1 <[email-masked]>, [email-masked]
Date: Fri, 26 Aug 2005 16:35:45 +0200

> In the past we have tried to avoid enumerations because of tooling 
> issues (schema generation, conversion, validation) as well as not 
> wishing to limit potential choices at the schema level.  I feel that 
> strict checking is best left to reference implementations that know what 
> values they wish to accept and reject.  Keeping the schema general 
> allows for easy extension; more specific schemas can be build from our 
> atoms to better fit the needs of designer.

OK. Note that for new readers lists make things simpler but I understand 
your concerns.

> 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.

Great. Then to sum-up, for now I saw only 2 issues with IPv6 and the 
current schema:

   - when type is hostname you don't know if name refers to an IPv6 or 
an IPv4 measurement
==> Need to make sure we have a type that qualifies an hostname 
referencing an IPv6 address

   - hosts have more than one IPv6 address per interface, some being 
local to the link (in fe80::/10 prefix). Note that site-local addresses 
have been deprecated and replaced by ULA's (Unique Local Addresses). 
These addresses should be considered as global addresses. (I personnaly 
think this is stupid but who cares...)
==> Need to have an array for ifAddress instead of a single element.

I'm happy to answer any question related to these things.

> It is possible to define new subject types when something doesn't fit 
> your needs, something such as mutlicastGroup (or even multicastGroupPing 
> as a subject in the ping.rnc if it is extremely specific) would more 
> than likely be needed in this situation.  Using the base and examples as 
> a road may we have always hoped that interested parties would add to our 
> work.

I think the multicastGroup could be needed for ping, and also for iperf. 
Another way to characterize it maybe is to define another 
multicast-ping.rnc and a multicast-iperf.rnc and define the pair with 
the source and the multicast address as destination. Then we could have 
results for each of the people in the group. I'm sorry I don't have time 
now to write it as an rnc to explain myself better. Do you see what I mean?

Jerome