[OPSAWG][IANA #1363823] Expert review for draft-ietf-opsawg-ipfix-tcpo-v6eh (ipfix)

2024-05-22 Thread David Dong via RT
Hi Paul,

Following up on this document as well.

Thank you for performing the reviews.

Best regards,

David Dong
IANA Services Sr. Specialist

On Tue May 14 05:21:33 2024, mohamed.boucad...@orange.com wrote:
> Hi Paul,
> 
> Thanks for double checking.
> 
> I don’t think there is a conflict between 3.3/3.4-3.6 because these
> are covering distinct aspects of the information export.
> 
> Fixed the nit.
> 
> Cheers,
> Med
> 
> De : Aitken, Paul 
> Envoyé : lundi 13 mai 2024 22:13
> À : BOUCADAIR Mohamed INNOV/NET ;
> drafts-expert-review-comm...@iana.org
> Cc : ie-doct...@ietf.org; opsawg 
> Objet : Re: [Ie-doctors] Re: [IANA #1363823] Expert review for draft-
> ietf-opsawg-ipfix-tcpo-v6eh (ipfix)
> 
> 
> Med,
> 
> 
> 3.3.
> 
> Extension headers observed in a Flow with varying extension header
> chain MAY be aggregated in one single ipv6ExtensionHeadersFull
> Information Element or be exported in separate
> ipv6ExtensionHeadersFull IEs, one for each extension header chain.
> 
> Seems to contradict these paragraphs:
> 
> 3.4.
> 
> Each header chain in Flow with varying extension header chain MUST
> be exported in a separate IE.
> 
> 3.6
> 
> Each header chain length of a Flow with varying extension header
> 
> chain MUST be exported in a separate
> 
> ipv6ExtensionHeadersChainLength IE.
> 
> 
> 
> 6.1. remove ",and" :
> 
> Figure 2 provides another example of reported values in an
> 
> ipv6ExtensionHeadersFull IE for an IPv6 Flow in which the Destination
> 
> Options (0), IPv6 Hop-by-Hop Options (1), and Routing (5), and
> 
> headers are observed.
> 
> P.
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les
> messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere,
> deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or
> privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have
> been modified, changed or falsified.
> Thank you.

___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org


[OPSAWG][IANA #1363823] Expert review for draft-ietf-opsawg-ipfix-tcpo-v6eh (ipfix)

2024-05-09 Thread David Dong via RT
Dear Authors/Chairs/ADs,

Please see below for feedback from the experts.

Best regards,

David Dong
IANA Services Sr. Specialist

On Wed May 08 09:42:59 2024, pait...@ciena.com wrote:
> 
> * 1.1
> 
> Add "the":
> 
> Section 3 addresses these issues.  Also, the ipv6ExtensionHeaders
> IPFIX
> IE is deprecated in favor of the new IEs defined in this document.
> 
> 
> * 1.2
> 
> Add "the" :
> 
> The specification of the tcpOptions IPFIX IE (209) does not:
> 
> Should "option" be "options"? :
> 
> *  Describe how some observed TCP options in a Flow can be exported
>using IPFIX.  Only TCP options having a Kind <= 63 can be exported
>in a tcpOptions IE.
> 
> Add "the" :
> 
> Section 4 addresses these issues.  Also, the tcpOptions IE is
> deprecated
> in favor of the new IEs defined in this document.
> 
> 
> * 2
> 
> Is the indentation correct here? :
> 
> Extension header chain:  Refers to the chain of extension headers
>that are present in an IPv6 packet.
> 
> This term should not be confused with the IPv6 header chain, which
> includes the IPv6 header, zero or more IPv6 extension headers, and
> zero or a single Upper-Layer Header.
> 
> 
> * 3.2
> 
> "the same" :
> 
> Description:  The number of consecutive occurrences of the same
>extension header type in a Flow.
> 
> 
> * 3.4
> 
> Add "ipv6ExtensionHeaderTypeCountList" :
> 
> If several extension header chains are observed in a Flow, each
> header chain MUST be exported in a separate
> ipv6ExtensionHeaderTypeCountList IE.
> 
> 
> * 3.5
> 
> What if both ipv6ExtensionHeadersFull and
> ipv6ExtensionHeaderTypeCountList are exported?
> [Later] this is discussed in section 5.1, but that wouldn't be known
> from reading the IPFIX registry alone. The fact that these IEs are
> mutually exclusive should be added to both IE descriptions.
> 
> 
> Description:  When set to "false", this Information Element indicates
>that the exported extension headers information (e.g.,
>ipv6ExtensionHeadersFull or ipv6ExtensionHeaderTypeCountList) does
>not match the full enclosed extension headers
> 
> 
> * 3.6
> 
> Change "identifying" to "to identify" :
> 
> Exporting such information might help
> to identify root causes of performance degradation, including
> packet drops.
> 
> How would we know which ipv6ExtensionHeadersChainLength IE corresponds
> with which header chain?
> 
> If several extension header chains are observed in a Flow, each
> header chain length MUST be exported in a separate
> ipv6ExtensionHeadersChainLength IE.
> 
> 
> * 5.1
> 
> "Will" sounds like a detail of a particular implementation. More
> generally this should be a "MUST", a "SHOULD", or a "MAY":
> 
> If an implementation determines that an observed packet of a Flow
> includes an extension header that it does not support, then the exact
> observed code of that extension header will be echoed in the
> ipv6ExtensionHeaderTypeCountList IE (Section 3.4).
> 
> 
> * 5.2
> 
> What does this mean? :
> 
> If a TCP Flow contains packets with a mix of 2-byte and 4-byte
> Experiment IDs, the same Template Record is used with both
> tcpSharedOptionExID16 and tcpSharedOptionExID32 IEs.
> 
> 
> 
> * 6.1
> 
> It would be helpful to list the corresponding header bit values, and
> to list them in order (0, 1, 5) rather than 1, 5, 0:
> 
> 
> Figure 1 provides an example of reported values in an
> ipv6ExtensionHeadersFull IE for an IPv6 Flow in which only the IPv6
> Destination Options header (0) is observed.
> 
> 
> Figure 2 provides another example of reported values in an
> ipv6ExtensionHeadersFull IE for an IPv6 Flow in which the IPv6 Hop-
> by-Hop Options (1), Routing (5), and Destination Options (0) headers
> are
> observed.
> 
> 
> * 6.2
> 
> It would be helpful to list the corresponding header bit values:
> 
> Figure 3 shows an example of reported values in a tcpOptionsFull IE
> for a TCP Flow in which End of Option List (0), Maximum Segment Size
> (2), and
> Window Scale (3) options are observed.
> 
> Please use the full 16-bit value, "0348" :
> 
> 1.  The tcpSharedOptionExID16 IE set to 0x0348454E to report observed
> 2-byte ExIDs: HOST_ID and TCP-ENO ExIDs.
> 
> 
> * 8.1
> 
> It's unclear which IE "this IE" is. eg, write "IE 209" if that's
> what's meant.
> 
> 
> *  Update the tcpOptions IE (209) entry by marking it as deprecated
>in favor of the tcpOptionsFull IE defined in this document.  This
>note should also be echoed in the "Additional Information" of this
>IE.
> 
> 
> * 8.4
> 
> This section sets up a potential conflict: what would happen if a new
> code was assigned to an IPv6 EH in [IANA-EH], but the expert reviewers
> disagreed with adding it to IPFIX?
> 
> Section 1.1 said, "how to automatically update the IANA IPFIX
> registry". Is expert review contrary to an automatic update?
> 
> 
> 
> * 8.4.1.
> 
> Typo in Initial Values:
> 
> +-+---+--+-+---+
> | 1   | HOP   | 0| Pv6 Hop-by-Hop Options  | This-D