Re: [ippm] Zaheduzzaman Sarker's No Objection on draft-ietf-ippm-rfc8889bis-02: (with COMMENT)

[Zaheduzzaman Sarker <[e-mail]>]

Hello,

 Thanks for addressing my comments.

See my reflections below prefixed with [ZS]

//Zahed


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

Thanks for working on this specification.

I am supporting Roman, John, Alvaro's discuss.

I have following comments which I believe would improve the document quality, if addressed.

## Section 2: I really didn't get the definition of the flow. May be it is my lack of expertise in English language or the technology used here but when the definition of flow is defined by flow ( is says- a flow can be multipoint-to-multipoint flow) it becomes very difficult to understand. Are we defining flow or identification of flow? It would be great to get a better description of the definition of  "flow". I also agree with John's comment that if a flow does not have traffic, is this also a flow? May be we merely defining the link between network nodes as flow, then I would say the term flow is overloaded.

Actually section 3 has a much better definition of flow. why don't we use that?

       "a flow can be defined by a set of selection rules used to
   match a subset of the packets processed by the network device.  These
   rules specify a set of Layer 3 and Layer 4 header fields
   (identification fields) and the relative values that must be found in
   matching packets"

[GF]: I see your point. To avoid confusion it is better to use only a single definition. I tend to agree that the definition in section 3 is more general and can be used to avoid misunderstanding.

[ZS] great.

## Section 2: according to the definition of the cluster, any single node can be a cluster and measure of the that cluster will be same as point to point measure defined in rfc8321bis (like node packet loss). is that correct interpretation? if yes, rfc8321bis becomes a subset of this specification, is that the intention?

[GF]: Yes it is correct.

[ZS] if this is correct then I wonder what value RFC8321bis brings here, we can just have one RFC to define the mechanism and cover both point to point and multipoint to multipoint. I wonder in the working group has already debated that possibility and decided to go with two different RFCs.



## Section 2.1 : as group to group segments are not used to define cluster in this specification, I would suggest following change -

       OLD text: the spatial metrics, used for measuring the performance of
       segments of a source to destination path, are applied here to
       group-to-group segments (called clusters).

       NEW text : the spatial metrics, used for measuring the performance of
       segments of a source to destination path, are applied here to
       clusters.

[GF]: Ok.

## Section 4.2 : What is "Non-initial fragments"?

[GF]: This definition is in RFC8321bis and means fragments originated by nodes within the domain. I have to add more explanation here or refer to RFC8321bis

[ZS] reference should work.

## I think it is confusing when terms defined in the terminology section get redefined in the later sections in a different way than how it is defined in the terminology section. the term "cluster" is an example of such case. can we stick to one single definition of cluster and other terms used in this document?

[GF]: Yes, as also raised in other reviews, I think it is better to define cluster only in the Terminology section and refer to it where needed. The same applies to the other terms.

[ZS] right.