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

From: "Jeff Meyer" <[email-masked]>
Date: Tue, 03 Feb 2004 19:06:04 -0800

Sebastian,

  So it sounds like consensus is that the information model will call 
section 6 the normative description of the information carried by IPFIX.  
The rationale being that interested parties will find it easier to review in 
this format and that any use of XML is optional in the IPFIX context.

  Appendix A (XML format) will remain, possibly being rolled to the XML 
format used by PSAMP, (waiting for those XSL stylesheets;-)

  The document will recommend that authors of IM extensions SHOULD use the 
XML format for authoring and utilize tools (pointers included in non 
normative reference section) to generate the normative "human readable" text 
and SHOULD include an XML based IM if one is produced.

-- 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: Tue, 03 Feb 2004 10:37:03 +0100
>
>Jeff Meyer wrote:
>>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 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?
>
>>
>>>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.
>
>When the text version is normative the IM is still extensible.
>
>>
>>>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?)
>
>Sure
>
>>>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.
>
>The result of using XML and not providing it is for the reader
>essentially the same as not using XML ;-)
>
>>>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!
>
>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.
>
>>>
>>>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.
>
>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.
>>
>>>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.
>
>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.
>
>>
>>>
>>>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.
>
>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.
>>>>
>>>>  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/
>>
>
>
>--
>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
>
>
>
>

_________________________________________________________________
High-speed users—be more efficient online with the new MSN Premium Internet 
Software. 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: Juergen Quittek <[email-masked]>
Date: Wed, 04 Feb 2004 09:37:48 +0100

Jeff,

--On 03.02.2004 19:06 Uhr -0800 Jeff Meyer wrote:

> The rationale being that interested parties will find it easier to
> review in this format and that any use of XML is optional in the
> IPFIX context.
>
>   The document will recommend that authors of IM extensions SHOULD use
> the XML format for authoring and utilize tools (pointers included in
> non normative reference section) to generate the normative "human readable"
> text and SHOULD include an XML based IM if one is produced.

This sounds very good to me.  I suggest adding another recommendation for
implementers to use the Appendix for generating code for IPFIX protocol
implementations.  In another step we could add an appendix to the protocol
document containing an XSL style sheet generating a C header out of the IM.
This XSL style sheet would implement the binary encoding rules stated in
plain text in the protocol document.

Thanks,

    Juergen

> High-speed users?be more efficient online with the new MSN Premium Internet Software. http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1
>

---

From: Sebastian Zander <[email-masked]>
Date: Wed, 04 Feb 2004 10:33:14 +0100

> plain text in the protocol document.

Sounds good! I'm not sure if the XSL belongs into the protocol draft. To be
consistent the other XSL would then go in the info draft? To make the drafts
shorter they could be made available separately and just referenced.

Sebastian

>> High-speed users?be more efficient online with the new MSN Premium 
>> Internet Software. 
>> 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

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 04 Feb 2004 15:21:50 +0100

Sebastian,

--On 04.02.2004 10:33 Uhr +0100 Sebastian Zander wrote:

> Sounds good! I'm not sure if the XSL belongs into the protocol draft.

I think it does.  It describe the data model of the IPFIX protocol
specification.  This is part of the protocol draft not of the information
model.

> To be consistent the other XSL would then go in the info draft?
> To make the drafts shorter they could be made available separately
> and just referenced.

Yes, we have to discuss this.  The problem is realizing what you call
"made available separately".
Has someone read already BCP 81, RFC 3688 on The IETF XML Registry?
This RFC was published just a few days ago. Maybe we find a good answer
in there ...

    Juergen