Hi Amanda,
On 8/26/2024 9:06 PM, Amanda Baber via RT wrote:
Hi Benoit,
A few IANA notes about version draft-ietf-opsawg-ipfix-on-path-telemetry-12:
1) Section 3.1 says, "All column entries besides the Identifier, Name, URI, Description, Output, and Reference Method categories are
the same," but it looks like "Output and Reference Method" should be replaced with something like "Reference
Description (Output only)." "Reference Method" is only a sentence long, and "Reference Description" appears to be
the only subsection under "Output" that has different text for different registrations.
We cut & pasted
"All column entries besides the Identifier, Name, URI, Description,
Output, and Reference Method categories are the same," from RFC 8912.
We could easily do
OLD:
"All column entries besides the Identifier, Name, URI, Description,
Output, and Reference Method categories are the same,"
NEW:
"All column entries besides the Identifier, Name, URI, Description,
Reference Description (Output only) categories are the same,"
Let us know your preference.
2) The Reference field that RFC 8911 (Section 7.1.5) places between the
Description and Change Controller appears to be missing.
Interestingly, it's not present in RFC8912, which we took as a reference.
Therefore it's not in IANA. See
https://www.iana.org/assignments/performance-metrics/RTDNS_Active_IP-UDP-Poisson_RFC8912sec6_Seconds_Raw
From RFC 8911:
7.1.5. Reference
This entry gives the specification containing the candidate Registry
Entry that was reviewed and agreed upon, if such an RFC or other
specification exists.
I guess this Reference field should be pointed to the RFC that created
that entry, so RFC 8912 in this above case, right?
Greg, as IPPM registry expert, do you confirm?
If we agree.
NEW INSERTION: 3.1.3 Reference
[RFC-to-be]
3) It's not totally clear (to IANA) what the Reference Description from the Output subsection would look
like in the registry. Would we remove "For all output types:" and "For each
<statistic> Singleton one of the following subsections applies" from Section 3.4.2, and then
include only the text of the relevant subsection, but without a subsection number and title?
If we take
https://www.iana.org/assignments/performance-metrics/RTDNS_Active_IP-UDP-Poisson_RFC8912sec6_Seconds_Raw,
as an example.
- we would keep the "For all output types:"
- you would remove the "For each <statistic> Singleton one of the
following subsections applies."
- "and then include only the text of the relevant subsection, but
without a subsection number and title?", yes
Example (for the first entry):
3.4.1.
<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-on-path-telemetry-12#section-3.4.1>Type
<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-on-path-telemetry-12#name-type>
OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Mean
The mean of the one-way delay of one IP packet is a Singleton
3.4.2.
<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-on-path-telemetry-12#section-3.4.2>Reference
Definition
<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-on-path-telemetry-12#name-reference-definition-2>
Similar to Section 7.4.2.2
<https://rfc-editor.org/rfc/rfc8912#section-7.4.2.2> of [RFC8912
<https://www.rfc-editor.org/info/rfc8912>], the mean SHALL be calculated
using the conditional distribution of all packets with a finite value of
one-way delay (undefined delays are excluded) -- a single value, as follows:
See Section 4.1 <https://rfc-editor.org/rfc/rfc3393#section-4.1> of
[RFC3393 <https://www.rfc-editor.org/info/rfc3393>] for details on the
conditional distribution to exclude undefined values of delay, and see
Section 5 <https://rfc-editor.org/rfc/rfc6703#section-5> of [RFC6703
<https://www.rfc-editor.org/info/rfc6703>] for background on this
analysis choice.See Section 4.2.2
<https://rfc-editor.org/rfc/rfc6049#section-4.2.2> of [RFC6049
<https://www.rfc-editor.org/info/rfc6049>] for details on calculating
this statistic; see also Section 4.2.3
<https://rfc-editor.org/rfc/rfc6049#section-4.2.3> of [RFC6049
<https://www.rfc-editor.org/info/rfc6049>].
Mean:
The time value of the result is expressed in units of seconds, as a
positive value of type decimal64 with fraction digits = 9 (similar
to the decimal64 in YANG, Section 9.3
<https://rfc-editor.org/rfc/rfc6020#section-9.3> of [RFC6020
<https://www.rfc-editor.org/info/rfc6020>]) with a resolution of
0.000000001 seconds (1.0 ns), and with lossless conversion to/from
the 64-bit NTP timestamp as per Section 6
<https://rfc-editor.org/rfc/rfc5905#section-6> of [RFC5905
<https://www.rfc-editor.org/info/rfc5905>].
I hope this is clear. Let us know.
Regards, Benoit
thanks,
Amanda
On Sat Aug 24 17:21:00 2024,benoit.cla...@huawei.com wrote:
Amanda,
[reduced distribution)
We posted v11, with the changes discussed at the last IETF.
Can you please double-check and reply to the OPSAWG mailer for
visibility.
Regards, Benoit
On 7/24/2024 10:33 PM, Amanda Baber via RT wrote:
Hi Benoit, all,
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-on-
path-telemetry-08
About Section 6.1: Should IANA separate the template in Section 3
into four separate templates, with information about the other
registrations removed from each, or can the same template be reused
four times?
We actually followed the example in RFC8912
OK. We'll separate them out and then ask you to confirm before
posting.
About Section 6.2: Should any of the information earmarked for the
“Reference” field be moved to the registry's “Additional
Information”
field? For examples, please see
https://www.iana.org/assignments/ipfix
That one is an important convention to agree upon early (this is the
first perf. metric IPFIX IE)
Let's take an example: 6.2.1. PathDelayMeanDeltaMicroseconds
Right now:
Reference: [RFC-to-be], OWDelay_HybridType1_Passive_IP_RFC[RFC-to-
be]_Seconds_Mean in the IANA Performance Metric Registry.
Your proposal
Reference: [RFC-to-be],
Additonal Information: OWDelay_HybridType1_Passive_IP_RFC[RFC-to-
be]_Seconds_Mean in the IANA Performance Metric Registry.
Your proposal would make sense in light
ofhttps://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-fixes/ ,
which says:
As discussed with IANA during the publication process of [RFC9487],
the "Additional Information" entry in [IANA-IPFIX] should contain a
link to an existing registry, when applicable, as opposed to having
Here is the key question: Since we have two registries as reference,
should we put them in "Reference"?
Or only use the IPFIX regisry information in the "Reference"?
As I mentioned, this is "just" a convention IMO.
Unless someone on the list has strong views, I propose that you,
IANA,
states the convention you want.
We would prefer that registries appear in the "Additional
Information" field and documents in the "Reference" field, as long as
an "Additional Information" field is available.
Apologies for the late response!
thanks,
Amanda
_______________________________________________
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
