Subject: [ipfix] [issue] INFO-29 Namespace definitions may need IANA considerations

From: "Jeff Meyer" <[email-masked]>
Date: Tue, 27 Jan 2004 23:55:29 -0800

The current info-model-02 specification contains references to XML type 
names and semantics borrowed directly from the XML-Schema specification as 
well as extensions.

Currently these extensions borrow from existing work of IPDR as well as 
newly identified types currently specific to IPFIX.

There are a few ways to address this.

The following e-mail thread discusses the options and opinion of this editor 
as well as opinions from Andrew Norton who is involved in IETF's and IANA's 
work in utilizing XML in RFC's.

Jeff,

It would seem that this is all a matter of "taste" as any of these options 
technically work.  Personally I would go with option 3; though it requires 
more coordination between organizations, to an outsider it would seem more 
cohesive.

There is a practical difference between option 1 and option 3 in terms of 
setting the standard.  With option 3, if IPDR upgrades their standard, the 
IPFIX group needs to do nothing to incorporate the changes.  However, with 
option 1, IPFIX will have to standardize a new schema and issue new RFC's.

-andy

Jeff Meyer wrote:
    Hi Andy,

I wanted to get your opinion on extending the XML-Schema type system for 
some specific information modeling requirements encountered by the IPFIX 
working group.

IPFIX currently reuses about 15 types from XML-Schema directly, however 
there are several types which are worthwile to distinguish from an IPFIX 
persepective which are not defined by XML-Schema.

These include types to identify timestamps of specific resolution (e.g. 
mSec, uSec, nSec), addressing types (IPv4 and IPv6 addresses) and one for 
UUIDs.

Today most of these extension types are defined in the public NDM-U 3.1.1 
specification from the industry consortium called IPDR.org.  There are a 
couple which are not are related to the high resolution timestamps (uSec and 
nSec).

The NDM-U 3.1.1 specificaiton is avaiable at 
http://www.ipdr.org/documents/NDM-U_3.1.1.pdf and specifically section 
A.4.4.

The IPFIX-Info reference is available at:

http://www.ipdr.org/documents/ipfix/infomodel/draft-ietf-ipfix-info-02.html#anchor4

This is a link to the specific secion in the HTML format of the info model 
based on RFC2629.

The quesion at hand is whether to follow one of the following 3 options:

   1. have a single XML-Schema which defines the extension types relevant to 
IPFIX and contained in the IPFIX namespace
   2. reference the existing types targeted by IPDR and add only the new 
types specific to the IPFIX Schema
   3. petition IPDR to define the remaining two IPFIX types for timestamps 
in their upcoming 3.5 specification (likely timeframe Feb. or March)

I get the impression from IPFIX discussions that referencing IPDR is 
something that some vocal participants find objectionable, i.e. they would 
prefer to see option 1.

My personal preference would be to go with option 3 or 2.  I believe 3 is 
doable and would reduce the number of places where people have to look for 
things.  Option 1 I see as creating some confusion in the space, but 
ultimately addressable through XSL or other mapping functions, if that's 
what it takes to get consensus.

Any guidance on your part would be appreciated.

Regards,

Jeff Meyer

_________________________________________________________________
Get a FREE online virus check for your PC here, from McAfee. 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 29 Jan 2004 13:31:19 +0100

Jeff,

I suggest to follow a completely different way of solving this
problems such that everybody get what is needed.

I see the cause in our dispute that the Appendix of the INFO model
document is NOT just an information model, but a data model.

As you argued well some time ago, it is a bad idea specifying
binary encodings in the info model document, because this would
already be a data model, which may vary among different protocols
that potentially use the IPFIX INFO model.

So, it is completely correct, that the binary encoding has become
a part of the IPFIX PROTOCOL document.  But still the IPFIX INFO
model document contains a data model: the XML ASCII encoding for
each information element. This is a data model. IMHO this is wrong!

We should follow a clean approach by just specifying an
information model.  This would solve several of the open issues
we are discussing, including the name space problem (iprd:),
because we get completely independent of these data encoding issues
and still can support IPDR data types in XML-based applications.

Here is my suggestion:

Currently, the Appendix is an XML schema defining which fixes ASCII
encodings for each information element.  I suggest to replace this
XML schema by an XML document.  The document would consist of a set
of XML element, each of them specifying a single information elements
with a set of attributes and/or contained XML elements exactly
covering all properties of information elements as defined in section 3.
(We can use a small, simple XML schema for checking consistency of this
XML document.)

Information elements defined this way would not have a standard XML,
IPDR, or other data type (data model should be separated from info model),
but would be defined just by English text, for example
  ipfix-int: integer value in the range of -2147483648 to 2147483647
  ipfix-dateTime: number of seconds since Jan 1st, 1970, 00:00 h
  ipfix-ipv4address: integral representation of a 32 bit IPv4 address
  ...
We would create our own IPFIX type space for the information elements.

Based on this pure information model, we can use XSLT (as we do it now)
to generate all the text in Section 6 describing the information elements.

Now, if you want to realize an XML-based application, you can take the
new XML document and use XSLT for automatic generation of a schema, such
as the one we have in the Appendix of the current version of the INFO model
document.  You see, you still have all the advantages of the machine-
readability and all opportunities to generate IPFIX XML parsers automatically.
But with the suggested change you would also have a clean information model
in the IPFIX INFO document avoiding all discussions on whether or not to
use the IPDR data types.

I am currently working together with Thomas, editor of the PSAMP INFO
model, to implement the idea sketched above. We will send an example to
this list in a few days.

Regards,

    Juergen

--On 27.01.2004 23:55 h -0800 Jeff Meyer wrote:

> The current info-model-02 specification contains references to XML type names and semantics borrowed directly from the XML-Schema specification as well as extensions.
>
> Currently these extensions borrow from existing work of IPDR as well as newly identified types currently specific to IPFIX.
>
> The following e-mail thread discusses the options and opinion of this editor as well as opinions from Andrew Norton who is involved in IETF's and IANA's work in utilizing XML in RFC's.
>
>
> Jeff,
>
> It would seem that this is all a matter of "taste" as any of these options technically work.  Personally I would go with option 3; though it requires more coordination between organizations, to an outsider it would seem more cohesive.
>
> There is a practical difference between option 1 and option 3 in terms of setting the standard.  With option 3, if IPDR upgrades their standard, the IPFIX group needs to do nothing to incorporate the changes.  However, with option 1, IPFIX will have to
> standardize a new schema and issue new RFC's.
>
> -andy
>
> Jeff Meyer wrote:
>     Hi Andy,
>
> I wanted to get your opinion on extending the XML-Schema type system for some specific information modeling requirements encountered by the IPFIX working group.
>
> IPFIX currently reuses about 15 types from XML-Schema directly, however there are several types which are worthwile to distinguish from an IPFIX persepective which are not defined by XML-Schema.
>
> These include types to identify timestamps of specific resolution (e.g. mSec, uSec, nSec), addressing types (IPv4 and IPv6 addresses) and one for UUIDs.
>
> Today most of these extension types are defined in the public NDM-U 3.1.1 specification from the industry consortium called IPDR.org.  There are a couple which are not are related to the high resolution timestamps (uSec and nSec).
>
> The NDM-U 3.1.1 specificaiton is avaiable at http://www.ipdr.org/documents/NDM-U_3.1.1.pdf and specifically section A.4.4.
>
> This is a link to the specific secion in the HTML format of the info model based on RFC2629.
>
>
>    1. have a single XML-Schema which defines the extension types relevant to IPFIX and contained in the IPFIX namespace
>    2. reference the existing types targeted by IPDR and add only the new types specific to the IPFIX Schema
>    3. petition IPDR to define the remaining two IPFIX types for timestamps in their upcoming 3.5 specification (likely timeframe Feb. or March)
>
> I get the impression from IPFIX discussions that referencing IPDR is something that some vocal participants find objectionable, i.e. they would prefer to see option 1.
>
> My personal preference would be to go with option 3 or 2.  I believe 3 is doable and would reduce the number of places where people have to look for things.  Option 1 I see as creating some confusion in the space, but ultimately addressable through XSL
> or other mapping functions, if that's what it takes to get consensus.
>
>
> Get a FREE online virus check for your PC here, from McAfee. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
>
>
> --