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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to