Subject: [IPFIX] IPFIX interop?

From: Benoit Claise <[email-masked]>
Date: Fri, 05 Oct 2012 16:24:30 +0200

Dear all,

At the last IETF Meeting, we discussed the possibility of an IPFIX interop.
To give some background information, the goal was mainly to progress 
RFC5101 to RFC5101bis.
However, based on the justification below (My email whose subject was 
"Re: [IPFIX] RFC 2026 versus RFC6410: progressing a document"), it's no 
required to test every single features to progress the standards track. 
So we could progress RFC5101bis.
So I guess that the IPFIX interop will not take place. Correct?

Regards, Benoit.

> Dear all,
>
> And I'm trying to compare the conditions to progress a document in RFC 
> 2026 and 6410
>
> RFC 2026:
>     The requirement for at least two independent and interoperable
>     implementations applies to all of the options and features of the
>     specification.In cases in which one or more options or features
>     have not been demonstrated in at least two interoperable
>     implementations, the specification may advance to the Draft Standard
>     level only if those options or features are removed.
>
> RFC 6410
>     The IESG, in an IETF-wide Last Call of at least four weeks, confirms
>     that a document advances from Proposed Standard to Internet Standard.
>     The request for reclassification is sent to the IESG along with an
>     explanation of how the criteria have been met.  The criteria are:
>
>     (1) There are at least two independent interoperating implementations
>         with widespread deployment and successful operational experience.
>
>      (2) There are no errata against the specification that would cause a
>         new implementation to fail to interoperate with deployed ones.
>
>     (3) There are no unused features in the specification that greatly
>         increase implementation complexity.
>
>     (4) If the technology required to implement the specification
>         requires patented or otherwise controlled technology, then the
>         set of implementations must demonstrate at least two independent,
>         separate and successful uses of the licensing process.
>
> After confirmation from the IESG, we don't need to test _every single 
> _feature from the specifications to progress the draft.
> However, the 4 points above must be respected.
>
> Regards, Benoit
>
>
>
>
>
>
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Brian Trammell <[email-masked]>
Date: Fri, 5 Oct 2012 16:28:31 +0200

Hi, Benoit, all,

I think we should definitely interop those features we haven't yet, and have as an action item for myself making sure that all of those features are supported in my current implementation, but I believe at this point in time it probably makes sense to try to organize pairwise testing as opposed to putting together another large everyone-in-a-room event, especially as it seems as there's not much energy among implementors for doing one of those again (the last one was in March 2011).

If 5101bis' progress doesn't gate on an interop, though, we can do one at our leisure, no?

Best regards,

Brian

On Oct 5, 2012, at 4:24 PM, Benoit Claise wrote:

> To give some background information, the goal was mainly to progress RFC5101 to RFC5101bis.
> However, based on the justification below (My email whose subject was "Re: [IPFIX] RFC 2026 versus RFC6410: progressing a document"), it's no required to test every single features to progress the standards track. So we could progress RFC5101bis.
>> And I'm trying to compare the conditions to progress a document in RFC 2026 and 6410
>> 
>> RFC 2026:
>>    specification.  
>> In cases in which one or more options or features
>> After confirmation from the IESG, we don't need to test every single feature from the specifications to progress the draft.

---

From: Benoit Claise <[email-masked]>
Date: Fri, 05 Oct 2012 16:56:49 +0200

Hi Brian, all,
> If 5101bis' progress doesn't gate on an interop, though, we can do one at our leisure, no?
Yes.

Regards, Benoit.