Re: [IPFIX] review of draft-ietf-ipfix-mediation-protocol-04

Brian,

> Okay, so the concrete terminological suggestion you're making is...
>
> NEW:
> Original Observation Point:   An Observation Point on a Metering
>          Process associated with the Original Exporter...
>
> correct?

That helps.


>>
>> It's opaque apart from the recently introduced special value, zero.
> (Where "recent" is "January 2008", with the publication of RFC 5101 (Section 3.1 "Message Header Format", description "Observation Domain ID", bottom of page 12).)

2008 wasn't so long ago?

The problem with these RFCs is that they make statements without making 
any implication about the opposite.

eg, the text in question says:

       The Observation
       Domain ID SHOULD be 0 when no specific Observation Domain ID is
       relevant for the entire IPFIX Message, for example, when exporting
       the Exporting Process Statistics, or in case of a hierarchy of
       Collectors when aggregated Data Records are exported.


Normally this would imply that an OD of zero indicates that no specific 
Observation Domain ID is relevant. However I've come to realise that 
it's incorrect to draw this conclusion because the text doesn't 
explicitly say that.


>> When a mediator or collector sees OD zero, it can't tell whether the export came from a simple device with only one OD, or from a complex device with multiple ODs using the "no specific Observation Domain ID is relevant" rule.
> I don't see the problem here. Why would a CP/mediator need to know something about the OD that the EP didn't export? From the standpoint of the protocol, OD 0 isn't really special -- it's a template and options scope as any other OD, with an added note that the CP should make no assumptions about the uniqueness of flows across records. Any other OD specific behavior is (1) interoperability-irrelevant and (2) implementation-specific.

You're not concerned about it. I'll let it go.


>> My concern is that although an implementation may not wish to export this option because it cannot be accurately or meaningfully measured, it may be obliged to export it for RFC compliance.
> Good point. There's 2119 creep here: the reliability records specified in RFC5101 and 5101bis are a MAY, in medproto they're a SHOULD. I suggest the fix here is to downgrade the requirement in section 10 of medproto to MAY:
>
> NEW:
>
>     IPFIX provides Options Templates for the reporting the reliability of
>     processes within the IPFIX Architecture.  As each Mediator includes
>     at least one IPFIX Exporting Process, they MAY use the Exporting
>     Process Reliability Statistics Options Template, as specified in
>     [I-D.ietf-ipfix-protocol-rfc5101bis].
>
>     Analogous to the Metering Process Reliability Statistics Options
>     Template, also specified in [I-D.ietf-ipfix-protocol-rfc5101bis],
>     Mediators MAY implement the Intermediate Process Reliability
>     Statistics Options Template, specified in the Section 10.1.
>
>     The Flow Keys Options Template, as specified in
>     [I-D.ietf-ipfix-protocol-rfc5101bis], may require special handling at
>     an IPFIX Mediator as described in Section 10.2.

Great.

>> That's exactly what I'm arguing. Provide an opt-out for the case that an implementer knows that this metric will be poor to meaningless, or impossible to implement.
> Okay, got it, and I agree. As above, MAY language would provide this opt-out.

Thanks,
P.

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix