Subject: RE: On the BLOB issue (Reinaldo-7, was: Re: [ipfix-req] list of i ssues - Reinaldo - 7 (or Carter -1))

From: "Reinaldo Penno" <[email-masked]>
Date: Fri, 25 Oct 2002 10:21:30 -0700

> -----Original Message-----
> From: Juergen Quittek [mailto:[email-masked]]
> Sent: Friday, October 25, 2002 10:00 AM
> To: [email-masked]
> Cc: Michael MacFaden; [email-masked]
> Subject: Re: On the BLOB issue (Reinaldo-7, was: Re: 
> [ipfix-req] list of
> issues - Reinaldo - 7 (or Carter -1))
> 
> 
> Paul,
> 
> -- [email-masked] wrote on 25 October 2002 11:43 -0400:
> 
> > Juergen Quittek wrote:
> >>
> >> Let's all have a look at our charter:
> >>
> >> 1. It starts with: "There are a number of IP flow information
> >>    export systems in common use."
> >>
> >> 2. Later it says: "This group will select a protocol ...".
> >>
> >> 3. There is no mentioning of "This group will merge all
> >>    protocols ...".
> >>    Also there is no mentioning of "This group will design a
> >>    protocol."
> >>
> >> Consequently, we should go on with what we have started already:
> >> selecting ONE of the candidate protocol.
> >>
> >> If the BLOB discussion ends up with saying "Just selecting one
> >> is a bad idea, we won't do it.", then we should stop our work and
> >> ask for re-chartering.
> >>
> >> However, I think, charter discussion was extensive and we made
> >> good progress based on the current charter. I definitely want
> >> to continue this.
> >
> >
> > 	I for one never expected to take the candidate
> > 	protocol on an "as is" basis.
> >
> > 	If we decide blobs are bad then the candidate
> > 	protocol needs to be modified accordingly.
> >
> > 	That applies to any other topic discussed as well.
> >
> > 	Paul
> 
> I do not have problems with giving recommendations to protocol
> designers to change their protocol. But as I understood the blob
> discussion, the idea was not to select one or the other protocol,
> but to select several and carry them all in an opaque blob.
> This is defintely more than modifying one of the protocols.

Hello Juergen,

I had a different understanding. The proposal was to be able to support
opaque objects in the standard IPfix protocol. that's one thing. Now, one of
the examples of its use was being able to carry data format of a
non-standard protocol, maybe in the transition period, maybe to satisfy some
deployed customer. But that was just an example, the idea was always to
select only one protocol.

regards,

Reinaldo

> 
>     Juergen
> 
> >>
> >>     Juergen
> >>
> >> -- Michael MacFaden wrote on 24 October 2002 19:58 -0700:
> >>
> >> > On Thu, Oct 24, 2002 at 07:28:21PM -0700, Reinaldo Penno wrote:
> >> >> That's the problem I foresee. Imagine how many data 
> types we will have in
> >> >> the future. All the combinations possible with all the 
> protocols that run
> >> >> over IP. Maybe what a vendor or its customer wants for 
> a certain scenario is
> >> >> a blob that contains, for instance, the DSCP field + 
> ECN + TCP window size.
> >> >> For other deployment I might need the URL + the Cache 
> header, etc, etc.
> >> >> Extrapolate that to all possible combinations and you 
> will see the profusion
> >> >> of new fields IANA will have to standardize, the size 
> of the parser, etc
> >> >
> >> > I do think we all agree the protocol must be extensible 
> as per the
> >> > requirements, but just not on the the scope yet. Some of us take
> >> > a narrow view of what the protocol should report (IPv4, 
> IPv6 headers)
> >> > others prefer a wider view (everything else).
> >> >
> >> > These divergent views will have to be considered 
> carefully in evaluating
> >> > how extensible the protocol should actually be. Section 
> 6.2 of the
> >> > requirements doc could then be updated to reflect the consensus.
> >> >
> >> > I will say it one last time and shut up.
> >> >
> >> > BLOBs hinder interoperability, BLOBs are bad.
> >> >
> >> > There. Peace Out.
> >> > Mike MacFaden
> >> >
> >> >
> >> > --
> >> > 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/
> >>
> >> --
> >> 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/
> 
> 
> 
> --
> 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: Sat, 26 Oct 2002 19:59:16 +0200

Reinaldo,

> select only one protocol.

Thank you for this clarification. It looks like I completely
misunderstood the proposal.

However, if it is just carrying additional information, then the
protocol extensibility requirement in Section 6.2 should include
already adding blobs to the bsobs (binary small objects) defined
in section 6.1.

I don't think a requirement like "The protocol MUST support exporting
an additional binary attribute with a format defined by some other
protocol." needs to be added.

    Juergen

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