Re: [Tsv-art] Tsvart early review of draft-ietf-opsawg-tsvwg-udp-ipfix-03

["[e-mail]" <[e-mail]>]

On Jan 2, 2024, at 9:07 AM, Tommy Pauly via Datatracker <[e-mail]> wrote:
> 
> Reviewer: Tommy Pauly
> Review result: Almost Ready
> 
> Thanks for writing a clear and succinct draft. I only found one issue of note,
> around the registration of the new udpOptions Information Element.
> 
> Section 4.1:
> The data type used for the “udpOptions” entry is just listed as “unsigned”, and
> is described as being either an unsigned32 or an unsigned64.

I understood this to be a bitfield of length 256, which MAY be shorter, and only in those shorter cases could it be UINT32 or UINT64, as per RFC7011. But that doesn’t seem consistent with RFC7011 either. AFAICT, this really should be octetArray, which COULD be shortened as needed.

> However, when I
> look at the registry at https://www.iana.org/assignments/ipfix/ipfix.xhtml, I
> don’t see any entries that use this abstract “unsigned” type, and it is not
> listed as an option in the element data types

I would think it should have been indicated as “octetArray”.

> . Is there a reason this shouldn’t
> just be registered as an unsigned64?

Yes, IMO - because UDP option Kind values higher than 63 are valid and could be used.

> My understanding from
> https://www.rfc-editor.org/rfc/rfc7011#section-6.2 is that an unsigned64 can be
> automatically encoded as an unsigned32 if the value is small enough, so the
> definition can just use unsigned64.

As per above, I don’t see how this helps given the field could be up to 265 bits long.

Joe