Dear OPSAWG, Med and Benoit Regarding section 6.2, forwardingStatus (https://datatracker.ietf.org/doc/html/draft-boucla-opsawg-ipfix-fixes-04#section-6.2). Section 4.12 of RFC 7270 (https://www.rfc-editor.org/rfc/rfc7270.html#section-4.12) describes that reduced-size encoding according to Section 6.2 of RFC 7011 (https://www.rfc-editor.org/rfc/rfc7011#section-6.2) can be applied. Further Section 4.12 of RFC 7270 describes that "The basic encoding is 8 bits. The future extensions could add one or three bytes". The IANA IPFIX registry (https://www.iana.org/assignments/ipfix/ipfix.xhtml) reads unisgned8 for IE89 forwardingStatus.
Recently we came across a vendor implementation which implemented IE89 forwardingStatus with unsigned32 instead of unsigned8 already. This raised the following questions which I like to clarify here: * Does "The future extensions could add one or three bytes" means that data type can be changed from unsigned8 to unsigned32 today already or is a new RFC document needed to update the IPFIX entity? * Does " reduced-size encoding" also applies for increasing the field size? If yes, I find the wording rather misleading. * If IE89 forwardingStatus can be implemented in unsigned8, unsigned16 and unsigned32, shouldn't it be reflected in the IPFIX registry accordingly? Depending on the answers we might take the opportunity with draft-boucla-opsawg-ipfix-fixes to update the IE89 forwardingStatus description. Best wishes Thomas
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg