Simple Two-Way Active Measurement Protocol
draft-ietf-ippm-stamp-10

Thank you for addressing my COMMENTs and DISCUSS items.

I'm strongly agreeing with Barry & Magnus' DISCUSSes.

I am agreeing with Barry's and Magnus' DISCUSSes.

Thanks for addressing my concern about the applicability in the new Section 5.

Thank you for addressing my Discuss points!

A few final comments on the -09, though I don't think any response is needed
for any of them:

There's still some editing for grammar to do, but I will trust in the RFC Editor
for that.

Section 4.2's use of RFC 6038 as a reference for "the symmetrical size of test packets"
with no section reference is a bit surprising, though perhaps not objectionable.

Section 4.6 has changed the discussion of reflected packet size in STAMP/TWAMP
interop scenarios, from "STAMP Session-Reflector will use a symmetric size"
to "STAMP Session-Reflector will always transmit the base packet (i.e., not a
symmetric size)".  I will trust you that this is accurate, since I cannot confirm it myself.

	1. Section 4: 
	Before using numbers from the User Ports range, the possible impact
   on the network MUST be carefully studied and agreed by all users of
   the network.
	
	Is the above sentence missing to list an important assumption? Is the assumption that by using the registred destination port an operator that sees to much STAMP traffic can simply filter it out and that way deal with the traffic, something which is not possible when using an locally decided port? If that is the case, this assumption should probably be noted. 
	
	2. Section 3 and 4, and 4.1.1: What is a STAMP Session? Is that a measurment session between one specific and sender and a specific reflector for a time duration?  The defenition of the session do matter if one intended to enable a single sender to use multiple reflectors, and if that can be a single session or always multiple indepdendent ones. Would appreciate a definition what a session is. If it is possible to send STAMP traffic using a multicast or broadcast address should be made explicit. 
	
	3.  Section 4.1.1.: 
	Timestamp is eight octets long field.  STAMP node MUST support
      Network Time Protocol (NTP) version 4 64-bit timestamp format
      [RFC5905], the format used in [RFC5357].  STAMP node MAY support
      IEEE 1588v2 Precision Time Protocol truncated 64-bit timestamp
      format [IEEE.1588.2008], the format used in [RFC8186].
	
	Is the clock source here something that may be relevant or simply information the management functions should capture. I think there is a similar issue to that of RTP faced when it comes to understand what the timestamp actually represent and thus be used correctly. RTP clock source specification is RFC 7273 (https://datatracker.ietf.org/doc/rfc7273/)
	
	4. Section 4.1: 
	   Because STAMP supports symmetrical test packets, STAMP Session-Sender
   packet has a minimum size of 44 octets in unauthenticated mode, see
   Figure 2, and 112 octets in the authenticated mode, see Figure 4.
	
	The above text implies some potential for UDP payload size variability for the STAMP packets. However, the actual definition appear to have fixed sizes. Can you please clarify if I have missed something that enables the STAMP packet to have variable size?

I support Barry's DISCUSS.

Also a few points are not clear:

   o  Stateless - STAMP Session-Reflector does not maintain test state
      and will reflect the received sequence number without
      modification.
This is not the only thing that the reflector reflects, right?

      The STAMP Session-Sender and Session-Reflector MAY use, not use,
      or set value of the Z field in accordance with the timestamp
      format in use.  This optional field is to enhance operations, but
      local configuration or defaults could be used in its place.
What do you mean by "use"and how does that differ from "set"?
Also the fact that it is described as optional here but as "MUST/SHOULD be set to NTP" in interop with TWAMP light is confusing.