[ippm] Zaheduzzaman Sarker's No Objection on draft-ietf-ippm-ioam-data-12: (with COMMENT)

[Zaheduzzaman Sarker via Datatracker <[e-mail]>]

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-ippm-ioam-data-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


I wanted to discuss about
 - IOAM domain isolation and boundary
.- needed integrity. It good that there is already intention to work with
integrity however, I felt the lack of integrity and impact of that needed to be
discussed already for this document.

However, my fellow ADs have already put DISCUSSes on those. I support Roman
Danyliw and Benjamin Kaduk's DISCUSSes.

Another major issue - the use of IOAM-Namespaces to provide domain isolation
needs to be clarified. It is described that IOAM-Namespaces can be used to
filter the IOAM-Domain. However, it is also described that the same node can
have different roles ( encapsulating, dencapsulating and transit) for different
Namespace. If both of the description is true then I don't think filtering
based on IAOM-Namesapces works or I dont understand the filtering concept here.

* Section 3:

   Should use the updated RFC 8174 version of the BCP 14 boilerplate.

   Nit:
        E2E        Edge to Edge
        PMTU       Path MTU
   Missing ":", where rest of the entries have them

       Geneve:    Generic Network Virtualization Encapsulation
              [I-D.ietf-nvo3-geneve]
   Should refer to RFC 8926.

* Section 4:
       The operator has to consider the
   potential operational impact of IOAM to mechanisms such as ECMP
   processing (e.g.  load-balancing schemes based on packet length could
   be impacted by the increased packet size due to IOAM)..

   is there any guideline available? I haven't seen any discussion in the
   security considerations on this matter either.

       IOAM control points: IOAM-Data-Fields are added to or removed from
   the live user traffic by the devices which form the edge of a domain.

   what is live user traffic here?  does this suppose to mean current traffic
   in transition within the IOAM domain?

       Devices which form an IOAM-Domain can add, update or remove IOAM-
   Data-Fields.  Edge devices of an IOAM-Domain can be hosts or network
   devices.

  "hosts" need to clarified more, host of what?

* Section 5.1 and 5.1.1 :
   I cannot find how a POT-profile is defined hence understanding of section
   5.1 and section 5.1.1 is troublesome. It would be good have description of
   the POT-profile prior to talk about it. If this is defined somewhere else
   then need to refer to that.

* Section 5.4.1:

      NodeLen:  5-bit unsigned integer.  This field specifies the length of
      data added by each node in multiples of 4-octets, excluding the
      length of the "Opaque State Snapshot" field.

   I would suggest to add reference to the section where the"Opaque state
   snapshot" is defined.

* Section 6.3 :

       Epoch:

      The epoch is 1 January 1970 00:00:00 TAI, which is 31 December
      1969 23:59:51.999918 UTC.

   AFAIK, the UNIX epoch is 1 January 1970 (midnight UTC/GMT). is there any
   reference to the Epoch used here?

* Section 7:

   Needs a reference to IPFIX