Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 vs.Appendix A

From: "Jeff Meyer" <[email-masked]>
Date: Mon, 02 Feb 2004 09:52:41 -0800

Sebastian,

  Comments inline...

-- Jeff

>From: Sebastian Zander <[email-masked]>
>To: Jeff Meyer <[email-masked]>
>CC: [email-masked], [email-masked], [email-masked],   
>[email-masked]
>Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 
>vs.Appendix A
>Date: Mon, 02 Feb 2004 14:48:22 +0100
>
>Jeff,
>
>I see the value of having an XML description

Good.

>but I agree to Juergen, Nevil
>and Stewart that the text should be the normative reference. I do not see
>the point of forcing people to use XML if they don't want to.

Do you mean "use" or "read" XML?  Assuming that you have a working XSL 
implementation the two forms are equivalent.

>I also do not
>see the point of extending the IM.

Huh?  Take a look at the requirements document, section 6.2:

   The data model MUST be extensible for future attributes to be added.
   Even if a set of attributes is fixed in the flow record, the data
   model MUST provide a way of extending the record by configuration or
   for certain implementations.

The term "data model" is misused here, but obviously from the context the 
intent is that extending the IM is a MUST.  PSAMP is a case in point.

>Most people will anyway read only the
>text and comment on this. So you have to do the XML editing anyway.

So you're saying one should write in XML?  (I agree, but it seems 
inconsistent with your previous statements?)

>As for
>IPFIX IM extensions not even the PSAMP IM draft currently uses the XML 
>model.

Read the thread more carefully.  They did use XML, they just didn't publish 
it, not very helpful.  As it stands I would need to cut and paste each 
subsection for each attribute of their work to operate with a system that is 
capable of directly a single XML document.

>Even worse the use of XML schema types like hexBinary has caused some 
>confusion
>among the authors.

"hexBinary" is a poorly chosen name.  If we embarked on reinventing things 
every time we disliked the names, then maybe we could solve the technology 
slump!  Jobs for everyone!

>
>I don't think that the use of XML in the IETF is as widely accepted as the
>use of MIBs. And how many IETF drafts provide normative textual 
>descriptions
>vs. how many provide normative XML schemas?

This seems to be simply an argument that change is bad.  That if things were 
one way before, embarking on something which might improve upon them should 
be viewed with great skepticism.

Obviously as new work there are a lot more MIBs which have had > 10 years to 
be built up vs. something which is proposed for IPFIX.

>The W3C schema definition is not
>even accepted by the whole XML community. There are alternatives e.g. RELAX 
>NG.

XML-Schema is the W3C specification.  Plain and simple.  Ultimately the 
utility is agreeing on one piece of work, which W3C did.

>
>Let's close this issue and move forward.

If both the XML and human readable forms are in the document, and assuming 
the process of converting from XML->human readable is automated using free 
and open tools, then I guess it really doesn't matter which one calls 
normative.

So, assuming we publish both, calling the text based normative to benefit 
readers unfamiliar with XML is an acceptable compromise.

If only human readable is contained in the document, as in the current PSAMP 
document, then I still have an issue.  You've taken away the more useful 
artifact of the two artifacts, the XML document which can be transformed 
into whatever you want it to be.

>
>A further point is whether IPFIX will standardize how to store the 
>information.
>1) AFAIK the idea of MIBs is to have a virtual information store. Do we 
>need an
>    IPFIX MIB? (PSAMP has a MIP draft already...)
>2) IMO the info model draft should focus on the definition of the 
>information
>    model and _not_ how to encode IPFIX information in XML.

The info model simply points out how because it is abstract and separate 
from encoding and transport, it may be applied to other activities dealing 
with IPFIX information.

Because MIBs typically deal with virtual stores of instantenous (vs. 
historical) information, they aren't very useful in the IPFIX context where 
enormous volumes of individual records are streaming off the device.   Yes, 
RMON is an example of a MIB which invented a complex indexing scheme to 
store historical information, while clever, I think it also illustrates some 
of the limitations/irritations of working with MIBs in this context.

A file format, or DB on the other hand is a handy way to capture these.  
Being able to "get this for free" seems like goodness to me.

>
>Cheers,
>
>Sebastian
>
>Jeff Meyer wrote:
>>Juergen,
>>
>>  I agree few protocols have formal model specs.  SNMP, however, which has 
>>as a key value proposition the means of extensibility chose to define 
>>MIBs, quite formal. MIBs also suffer somewhat from difficulty in reading 
>>along with some other issues inherited from ASN.1 which are improved by 
>>XML.
>>
>>  Since I believe one of the key aspects of IPFIX is the mechanism for 
>>extension, I think we should learn from another IETF protocol which seemed 
>>rather successful in addressing this requirement.
>>
>>  So, I think maintaining the connection between the mechanism which is 
>>available today in IPFIX-info to formally specify the model is important, 
>>if there is an interest in drawing others to extend IPFIX with information 
>>content which differs from IPFIX's initial focus.
>>
>>  One approach would be to break out another document as part of IPFIX, 
>>which would be something like  "Formal IPFIX Information Modeling".  But 
>>I'm not particularly eager to create another document.
>>
>>-- Jeff
>>
>>
>>>From: Juergen Quittek <[email-masked]>
>>>To: Jeff Meyer <[email-masked]>, [email-masked]
>>>CC: [email-masked], [email-masked]
>>>Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 
>>>vs.Appendix A
>>>Date: Thu, 29 Jan 2004 12:30:58 +0100
>>>
>>>Jeff,
>>>
>>>We had this entire discussion already some time ago.
>>>
>>>For me, the main argument is that all IETF standards so far
>>>are human-readable.  The XML document in the Appendix is hardly
>>>readable, while section 6 is well readable.
>>>
>>>You are requesting to move from a human-readable standard
>>>to a machine-readable standard.  I understand that there are
>>>several good reasons to do so.  But the change in the
>>>standardization approach is fundamental.
>>>
>>>This might be an issue for the ietf@ieft mailing list.
>>>However, so far very few protocols or models in the IETF
>>>have been formally defined. Looks like still the 'running
>>>code' approach dominates the 'well specified' approach.
>>>
>>>Regards,
>>>
>>>     Juergen
>>>
>>>--On 28.01.2004 19:53 h -0800 Jeff Meyer wrote:
>>>
>>>>Nevil,
>>>>
>>>>   My only contention would be that I did not do any direct data entry 
>>>>for section 6.  I.e. I wrote the XML-Schema ran it through the publicly 
>>>>available stylesheet and free transform engine and pasted it into the 
>>>>doc.
>>>>
>>>>   Certainly it would be my hope that authors of additional information 
>>>>models to be carried over IPFIX would follow the same process, because 
>>>>then I can simply take their XML-Schema spec and use it in a variety of 
>>>>tools.  If I only get text, then I
>>>>have the tedious prospect of transcribing it.  If equipment providers 
>>>>favor a manual transcription process, it is certainly not precluded.
>>>>
>>>>   My understanding was that PSAMP might be using the XML technique 
>>>>today, I believe it was Juergen who asked about the tools and I passed 
>>>>along the pointer.
>>>>
>>>>   If it is politically simpler to call section 6 normative but indicate 
>>>>that authors of new models SHOULD create an XML-Schema model and MAY 
>>>>machine translate these models to create the normative text, then I 
>>>>could live with such a compromise.
>>>>
>>>>   Simply excising this information as Stewart seems to be advocating 
>>>>seems like a step backwards and I'm at a loss to see any benefit from 
>>>>that.
>>>>
>>>>Regards,
>>>>
>>>>   Jeff Meyer
>>>>
>>>>
>>>>>From: Nevil Brownlee <[email-masked]>
>>>>>To: Jeff Meyer <[email-masked]>
>>>>>CC: [email-masked], [email-masked]
>>>>>Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6
>>>>>vs.Appendix A
>>>>>Date: Thu, 29 Jan 2004 13:02:07 +1300
>>>>>
>>>>>Stewart and Jeff:
>>>>>
>>>>> >   With the use of XSL stylesheets the XML style informaiton model 
>>>>>could
>>>>>be
>>>>> > transformed automatically into any set of text one would want, e.g. 
>>>>>IOS
>>>>> > commands to enable flags, HTML tables for presentation, RFC2629 
>>>>>entries
>>>>>in
>>>>> > an RFC document, etc.  For a discussion and example of using free 
>>>>>XSL
>>>>>tools
>>>>> > to process this you can see
>>>>> > http://www.ipdr.org/documents/ipfix/infomodel/README.html.
>>>>>
>>>>>Jeff's right in saying that XML is becoming more widely used within the
>>>>>IETF, as evidenced by RFC 2629 and the fact that more WGs (espcially
>>>>>in the Applications Area) are using it.
>>>>>
>>>>>However, RFC 2629 explicitly says it doesn't address "IETF politics"
>>>>>issues.  My take on that is that the text in section 6 of the Info 
>>>>>Model
>>>>>draft is the normative version; Appendix A gives the xml because people
>>>>>may find it useful, but if they use it they should check that it really
>>>>>does match the (normative) text version.
>>>>>
>>>>>As for IPFIX WG consensus on this, in my view the document editors
>>>>>are free to use whatever tools they need to produce the actual drafts.
>>>>>Furthermore, including the xml as an appendix allows other people to
>>>>>use the xml for other purposes, which (I guess) is why the editors
>>>>>appended it to the draft.
>>>>>
>>>>>Does that make the situation clearer?
>>>>>
>>>>>-----------------------------------------------------------------------
>>>>>    Nevil Brownlee                   Director, Technology Development
>>>>>    Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
>>>>>    FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand
>>>>>
>>>>>
>>>>>-------------------------------------------------
>>>>>This mail sent through University of Auckland
>>>>>http://www.auckland.ac.nz/
>>>>>
>>>>>--
>>>>>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/
>>>>
>>>>
>>>>_________________________________________________________________
>>>>Learn how to choose, serve, and enjoy wine at Wine @ MSN. 
>>>>http://wine.msn.com/
>>>>
>>>>
>>>>--
>>>>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/
>>>
>>>
>>>
>>>
>>>
>>
>>_________________________________________________________________
>>There are now three new levels of MSN Hotmail Extra Storage!  Learn more. 
>>http://join.msn.com/?pgmarket=en-us&page=hotmail/es2&ST=1
>>
>>
>>--
>>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/
>>
>
>
>--
>Sebastian Zander                         E-mail: [email-masked]
>Fraunhofer FOKUS / METEOR                Tel: +49-30-3463-7287
>Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287
>D-10589 Berlin, Germany                  
>www.fokus.fraunhofer.de/usr/sebastian.zander
>
>
>
>

_________________________________________________________________
Let the new MSN Premium Internet Software make the most of your high-speed 
experience. http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1

--
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: Stewart Bryant <[email-masked]>
Date: Tue, 03 Feb 2004 09:37:41 +0000

> implementation the two forms are equivalent.

But the point is that we should not require engineers to have a running
XSL implementation just to check a normative statement. The IETF tradition,
which has served us well over the years, is that we just need an
ascii text viewer to read an IETF specification.

>> see the point of extending the IM.

Here I disagree, the IM must be extensible.

> 
> 
> "hexBinary" is a poorly chosen name.  If we embarked on reinventing 
> things every time we disliked the names, then maybe we could solve the 
> technology slump!  Jobs for everyone!

"4.7 hexBinary

    The type "hexBinary" represents a finite length string of octets."

I am sure that if you asked most IETF members what a hexBinary was,
they would say that it was the representation of a set of bits (a
binary number) in hexadecimal notation. If it is anything other than
that I think we need to find a better name.

- Stewart

---

From: Sebastian Zander <[email-masked]>
Date: Tue, 03 Feb 2004 10:37:03 +0100

Jeff Meyer wrote:
>> CC: [email-masked], [email-masked], 
>> [email-masked],   [email-masked]

I would assume that most people who are not going to use XML won't read it.
Why should they if the text contains the same information more readable?

> The term "data model" is misused here, but obviously from the context 
> the intent is that extending the IM is a MUST.  PSAMP is a case in point.

When the text version is normative the IM is still extensible.

> inconsistent with your previous statements?)

Sure

> Read the thread more carefully.  They did use XML, they just didn't 
> publish it, not very helpful.  As it stands I would need to cut and 
> paste each subsection for each attribute of their work to operate with a 
> system that is capable of directly a single XML document.

The result of using XML and not providing it is for the reader
essentially the same as not using XML ;-)

> technology slump!  Jobs for everyone!

The fact is that the type specifies how to encode binary field in XML which
is not the job of the information model and which is the reason why Juergen
and I propose to use a XML document instead of a schema.

> This seems to be simply an argument that change is bad.  That if things 
> were one way before, embarking on something which might improve upon 
> them should be viewed with great skepticism.

You miss the point. I'm not against change but I'm not convinced by your
arguments.

> Obviously as new work there are a lot more MIBs which have had > 10 
> years to be built up vs. something which is proposed for IPFIX.
> 
>> even accepted by the whole XML community. There are alternatives e.g. 
>> RELAX NG.
> 
> 
> If both the XML and human readable forms are in the document, and 
> assuming the process of converting from XML->human readable is automated 
> using free and open tools, then I guess it really doesn't matter which 
> one calls normative.
> 
> So, assuming we publish both, calling the text based normative to 
> benefit readers unfamiliar with XML is an acceptable compromise.

Great!

> If only human readable is contained in the document, as in the current 
> PSAMP document, then I still have an issue.  You've taken away the more 
> useful artifact of the two artifacts, the XML document which can be 
> transformed into whatever you want it to be.

Can we mandate that extensions provide XML? I have the feeling that this
won't get consensus. Solution could be to recommend it.

At least you can always produce the XML from the text. Assuming that authors
use a consistent format this can be done automatically.

I don't think that PSAMP is a big problem because it seems well aligned with
IPFIX but in the future other extensions may be created from people not
involved in the initial IPFIX or PSAMP work.

>> 1) AFAIK the idea of MIBs is to have a virtual information store. Do 
>> we need an
> from encoding and transport, it may be applied to other activities 
> dealing with IPFIX information.
> 
> historical) information, they aren't very useful in the IPFIX context 
> where enormous volumes of individual records are streaming off the 
> device.   Yes, RMON is an example of a MIB which invented a complex 
> indexing scheme to store historical information, while clever, I think 
> it also illustrates some of the limitations/irritations of working with 
> MIBs in this context.
> 

It appears to me that a MIB for the configuration of IPFIX devices could be
a good idea.

For IPFIX data I'm not sure either. RTFM is another example which has defined
a MIB for flow data...

Cheers,

Sebastian

>>
>> Cheers,
>>
>> Sebastian
>>
>> Jeff Meyer wrote:
>>
>>> Juergen,
>>>
>>>  I agree few protocols have formal model specs.  SNMP, however, which 
>>> has as a key value proposition the means of extensibility chose to 
>>> define MIBs, quite formal. MIBs also suffer somewhat from difficulty 
>>> in reading along with some other issues inherited from ASN.1 which 
>>> are improved by XML.
>>>
>>> extension, I think we should learn from another IETF protocol which 
>>> seemed rather successful in addressing this requirement.
>>>
>>>  So, I think maintaining the connection between the mechanism which 
>>> is available today in IPFIX-info to formally specify the model is 
>>> important, if there is an interest in drawing others to extend IPFIX 
>>> with information content which differs from IPFIX's initial focus.
>>>
>>>  One approach would be to break out another document as part of 
>>> IPFIX, which would be something like  "Formal IPFIX Information 
>>> Modeling".  But I'm not particularly eager to create another document.
>>>
>>> -- Jeff
>>>
>>>
>>>>>   My only contention would be that I did not do any direct data 
>>>>> entry for section 6.  I.e. I wrote the XML-Schema ran it through 
>>>>> the publicly available stylesheet and free transform engine and 
>>>>> pasted it into the doc.
>>>>>
>>>>>   Certainly it would be my hope that authors of additional 
>>>>> information models to be carried over IPFIX would follow the same 
>>>>> process, because then I can simply take their XML-Schema spec and 
>>>>> use it in a variety of tools.  If I only get text, then I
>>>>> have the tedious prospect of transcribing it.  If equipment 
>>>>> providers favor a manual transcription process, it is certainly not 
>>>>> precluded.
>>>>>
>>>>> today, I believe it was Juergen who asked about the tools and I 
>>>>> passed along the pointer.
>>>>>
>>>>>   If it is politically simpler to call section 6 normative but 
>>>>> indicate that authors of new models SHOULD create an XML-Schema 
>>>>> model and MAY machine translate these models to create the 
>>>>> normative text, then I could live with such a compromise.
>>>>>
>>>>>   Simply excising this information as Stewart seems to be 
>>>>> advocating seems like a step backwards and I'm at a loss to see any 
>>>>> benefit from that.
>>>>>
>>>>> Regards,
>>>>>
>>>>>   Jeff Meyer
>>>>>
>>>>>
>>>>>> >   With the use of XSL stylesheets the XML style informaiton 
>>>>>> model could
>>>>>> be
>>>>>> > transformed automatically into any set of text one would want, 
>>>>>> e.g. IOS
>>>>>> > an RFC document, etc.  For a discussion and example of using 
>>>>>> free XSL
>>>>>> tools
>>>>> message body
>>> There are now three new levels of MSN Hotmail Extra Storage!  Learn 
>>> more. http://join.msn.com/?pgmarket=en-us&page=hotmail/es2&ST=1
>>>
>>>
>>> -- 
>>> message body
> Let the new MSN Premium Internet Software make the most of your 
> high-speed experience. 
> http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1
> 
> 
> -- 

-- 
Sebastian Zander                         E-mail: [email-masked]
Fraunhofer FOKUS / METEOR                Tel: +49-30-3463-7287
Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287
D-10589 Berlin, Germany                  www.fokus.fraunhofer.de/usr/sebastian.zander