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

Note: This ballot was opened for revision 07 and is now closed.

Mirja K├╝hlewind Yes

Deborah Brungard No Objection

Roman Danyliw (was Discuss) No Objection

Comment (2019-10-20 for -09)
No email
send info
Thank you for addressing my COMMENTs and DISCUSS items.

Benjamin Kaduk (was Discuss) No Objection

Comment (2019-10-23 for -09)
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.

Suresh Krishnan No Objection

Warren Kumari No Objection

Comment (2019-09-04 for -07)
No email
send info
I'm strongly agreeing with Barry & Magnus' DISCUSSes.

Barry Leiba (was Discuss) No Objection

Comment (2019-09-25 for -08)
No email
send info
Thanks for addressing my concern about the applicability in the new Section 5.

Alexey Melnikov No Objection

Comment (2019-09-04 for -07)
No email
send info
I am agreeing with Barry's and Magnus' DISCUSSes.

Alvaro Retana No Objection

Adam Roach No Objection

Martin Vigoureux No Objection

Comment (2019-09-05 for -07)
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.

Magnus Westerlund (was Discuss) No Objection

Comment (2019-09-04 for -08)
No email
send info
	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?