Simple Two-Way Active Measurement Protocol
draft-ietf-ippm-stamp-10
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-03-17
|
10 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-03-11
|
10 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-02-10
|
10 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2020-01-14
|
10 | (System) | RFC Editor state changed to EDIT from MISSREF |
2019-11-14
|
10 | (System) | IANA Action state changed to No IANA Actions from In Progress |
2019-11-13
|
10 | (System) | RFC Editor state changed to MISSREF |
2019-11-13
|
10 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-11-13
|
10 | (System) | Announcement was received by RFC Editor |
2019-11-13
|
10 | (System) | IANA Action state changed to In Progress |
2019-11-13
|
10 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2019-11-13
|
10 | Cindy Morgan | IESG has approved the document |
2019-11-13
|
10 | Cindy Morgan | Closed "Approve" ballot |
2019-11-13
|
10 | Cindy Morgan | Ballot approval text was generated |
2019-11-13
|
10 | Mirja Kühlewind | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2019-10-31
|
10 | Greg Mirsky | New version available: draft-ietf-ippm-stamp-10.txt |
2019-10-31
|
10 | (System) | New version approved |
2019-10-31
|
10 | (System) | Request for posting confirmation emailed to previous authors: Gregory Mirsky , Henrik Nydell , Richard Foote , Guo Jun |
2019-10-31
|
10 | Greg Mirsky | Uploaded new revision |
2019-10-23
|
09 | Benjamin Kaduk | [Ballot comment] Thank you for addressing my Discuss points! A few final comments on the -09, though I don't think any response is needed for … [Ballot comment] 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. |
2019-10-23
|
09 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2019-10-20
|
09 | Roman Danyliw | [Ballot comment] Thank you for addressing my COMMENTs and DISCUSS items. |
2019-10-20
|
09 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss |
2019-10-18
|
09 | Greg Mirsky | New version available: draft-ietf-ippm-stamp-09.txt |
2019-10-18
|
09 | (System) | New version approved |
2019-10-18
|
09 | (System) | Request for posting confirmation emailed to previous authors: Gregory Mirsky , Henrik Nydell , Richard Foote , Guo Jun |
2019-10-18
|
09 | Greg Mirsky | Uploaded new revision |
2019-10-18
|
08 | Gunter Van de Velde | Assignment of request for Last Call review by OPSDIR to Joel Jaeggli was marked no-response |
2019-09-26
|
08 | Magnus Westerlund | [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss |
2019-09-25
|
08 | Barry Leiba | [Ballot comment] Thanks for addressing my concern about the applicability in the new Section 5. |
2019-09-25
|
08 | Barry Leiba | [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss |
2019-09-24
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-09-24
|
08 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2019-09-24
|
08 | Greg Mirsky | New version available: draft-ietf-ippm-stamp-08.txt |
2019-09-24
|
08 | (System) | New version approved |
2019-09-24
|
08 | (System) | Request for posting confirmation emailed to previous authors: Gregory Mirsky , Henrik Nydell , Richard Foote , Guo Jun |
2019-09-24
|
08 | Greg Mirsky | Uploaded new revision |
2019-09-10
|
07 | Dale Worley | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Dale Worley. |
2019-09-05
|
07 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from Waiting for AD Go-Ahead |
2019-09-05
|
07 | Martin Vigoureux | [Ballot comment] I support Barry's DISCUSS. Also a few points are not clear: o Stateless - STAMP Session-Reflector does not maintain test state … [Ballot comment] 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. |
2019-09-05
|
07 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2019-09-04
|
07 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2019-09-04
|
07 | Roman Danyliw | [Ballot comment] I support Barry Leiba’s DISCUSS. I also support Magnus Westerlund’s DISCUSS. See #4. (updated ballot) I also support Ben Kaduk's DISCUSS. (2) Section … [Ballot comment] I support Barry Leiba’s DISCUSS. I also support Magnus Westerlund’s DISCUSS. See #4. (updated ballot) I also support Ben Kaduk's DISCUSS. (2) Section 4.1.1. The sequence number is defined in terms of a “new session”. However, I couldn’t find the precise definition of a “session” – how is new one initiated? terminated? (3) Section 4.2.1. Per Session-Sender TTL, this field is defined, the guidance on generating its value is clear, but its use is not explained. (4) Section 4.3. Related question to Magnus Westerlund’s DISCUSS, what is the planned approach for crypto agility? (5) Section 4.3. Per, “HMAC uses its own key, and the definition of the mechanism to distribute the HMAC key is outside the scope of this specification.” -- What is being suggested by “uses its own key”? -- Is it expected that each Session-Sender/Reflector pair would have a unique key? -- Recommend being clearer on what’s out of scope, perhaps something on the order of: s/… the definition of the mechanism to distribute the HMAC key is outside the scope of this specification./ … key management and the mechanisms to distribute the HMAC key is outside the scope of this specification.” (5) Section 4.3. Thanks for responded to Russ Housley’s SECDIR review and proposing the new Section 4.3 and 4.4. It provides helpful clarity. (6) Editorial Nits -- Section 3. I didn’t understand the title of ‘Softwarization of Performance Management’. The text of the section seems to simply describe the elements of Figure 1 and suggests a few ways to configure the these elements. -- Section 4. Typo. s/MUST use received/MUST received/ -- Section 6. Editorial. s/Load of STAMP test packets/The load of the STAMP test packets/ |
2019-09-04
|
07 | Roman Danyliw | Ballot comment text updated for Roman Danyliw |
2019-09-04
|
07 | Roman Danyliw | [Ballot discuss] (1) Section 4.3. The text does not explicitly state the data on which the HMAC is computed (i.e., bytes 1 to the end … [Ballot discuss] (1) Section 4.3. The text does not explicitly state the data on which the HMAC is computed (i.e., bytes 1 to the end of the last MBZ field of the message?) (2) Section 6. Per “In general, all the security considerations related to TWAMP-Test, discussed in [RFC5357] apply to STAMP.”, what exact guidance is relevant here: -- Section 6 (Security Considerations) of RFC5357 says follow the guidance of RFC4656 and guidance on the OWAMP Server-Greeting messages, only the former seems relevant -- Section 6 (Security Considerations) of RFC4656 has: Section 6.1 which discusses authenticated and encrypted mode of OWAMP; but STAMP has no encrypted mode. The claims about authenticate mode seem to be similar to OWAMP, but that’s not explicitly said Section 6.2 discusses DoS, seems to have some related guidance but also discusses TCP handshakes Section 6.3 discusses covert channels, this seems relevant Section 6.4 seems to discuss key management that section 4.3 of this draft seems to suggest is out of scope Section 6.5 seems to provide guidance on resource provisioning but uses the KeyID primitive that doesn’t appear present in this draft [please review the other sections too ...] |
2019-09-04
|
07 | Roman Danyliw | Ballot discuss text updated for Roman Danyliw |
2019-09-04
|
07 | Roman Danyliw | [Ballot discuss] (1) Section 4.3. The text does not explicitly state the data on which the HMAC is computed (i.e., bytes 1 to the end … [Ballot discuss] (1) Section 4.3. The text does not explicitly state the data on which the HMAC is computed (i.e., bytes 1 to the end of the last MBZ field of the message?) (2) Section 6. Per “In general, all the security considerations related to TWAMP-Test, discussed in [RFC5357] apply to STAMP.”, what exact guidance is relevant here: -- Section 6 (Security Considerations) of RFC5357 says follow the guidance of RFC4656 and guidance on the OWAMP Server-Greeting messages, only the former seems relevant -- Section 6 (Security Considerations) of RFC4656 has: Section 6.1 which discusses authenticated and encrypted mode of OWAMP; but STAMP has no encrypted mode. The claims about authenticate mode seem to be similar to OWAMP, but that’s not explicitly said Section 6.2 discusses DoS, seems to have some related guidance but also discusses TCP handshakes Section 6.3 discusses covert channels, this seems relevant Section 6.4 seems to discuss key management that section 4.3 of this draft seems to suggest is out of scope Section 6.5 seems to provide guidance on resource provisioning but uses the KeyID primitive that doesn’t appear present in this draft […] |
2019-09-04
|
07 | Roman Danyliw | [Ballot comment] I support Barry Leiba’s DISCUSS. I also support Magnus Westerlund’s DISCUSS. See #4. (2) Section 4.1.1. The sequence number is defined in terms … [Ballot comment] I support Barry Leiba’s DISCUSS. I also support Magnus Westerlund’s DISCUSS. See #4. (2) Section 4.1.1. The sequence number is defined in terms of a “new session”. However, I couldn’t find the precise definition of a “session” – how is new one initiated? terminated? (3) Section 4.2.1. Per Session-Sender TTL, this field is defined, the guidance on generating its value is clear, but its use is not explained. (4) Section 4.3. Related question to Magnus Westerlund’s DISCUSS, what is the planned approach for crypto agility? (5) Section 4.3. Per, “HMAC uses its own key, and the definition of the mechanism to distribute the HMAC key is outside the scope of this specification.” -- What is being suggested by “uses its own key”? -- Is it expected that each Session-Sender/Reflector pair would have a unique key? -- Recommend being clearer on what’s out of scope, perhaps something on the order of: s/… the definition of the mechanism to distribute the HMAC key is outside the scope of this specification./ … key management and the mechanisms to distribute the HMAC key is outside the scope of this specification.” (5) Section 4.3. Thanks for responded to Russ Housley’s SECDIR review and proposing the new Section 4.3 and 4.4. It provides helpful clarity. (6) Editorial Nits -- Section 3. I didn’t understand the title of ‘Softwarization of Performance Management’. The text of the section seems to simply describe the elements of Figure 1 and suggests a few ways to configure the these elements. -- Section 4. Typo. s/MUST use received/MUST received/ -- Section 6. Editorial. s/Load of STAMP test packets/The load of the STAMP test packets/ |
2019-09-04
|
07 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
2019-09-04
|
07 | Benjamin Kaduk | [Ballot discuss] We don't ever clearly state that the protocol allows for packet sizes other than the listed 44- and 112-octet variants, that content larger … [Ballot discuss] We don't ever clearly state that the protocol allows for packet sizes other than the listed 44- and 112-octet variants, that content larger than that is to be treated as padding unless directed otherwise by configuration, that the reflected packet must be the same size as the incoming packet, and how a Session-Reflector should set any such padding that it needs to add in order to produce a same-sized packet. This document hardcodes the truncated HMAC-SHA-256 algorithm. Per BCP 201, what is the procedure for cryptographic algorithm agility? Please also consider the discussion in BCP 107 about key lifecycles and key management, including whether it is appropriate to use a key-derivation function to produce short-term (e.g., per flow) keys from a long-lived key (e.g., one fixed in static configuration). What is the input plaintext to the HMAC computation? In the case of future extensions, does the HMAC field remain at its current fixed offset in the packet or move to always be the last 16 octets? Is any additional padding/TLV content protected by the HMAC? What error does the error estimate ... estimate? Clock skew between sender and receiver? I think we need to require some level of cryptographic protection whenever control information is included in a Session-Sender's test packet. That is, that a Session-Reflector MUST NOT act on control information received in unauthenticated packets. (That said, this document itself does not describe a way to include control information, so perhaps the note about "optional control information communicated in the Session-Sender's test packet" in Section 4 is misplaced. In Section 4.2.1: o Timestamp and Receiver Timestamp fields are each eight octets long. The format of these fields, NTP or PTPv2, indicated by the Z flag of the Error Estimate field as described in Section 4.1. I think you need to explicitly say that "Timestamp" is echoed from the received packet and "Receiver Timestamp" is determined locally as close to (reciept? transmission?) as possible. I think we need greater clarity on whether the normative statements in Section 4.4 apply only to STAMP peers that are aware they are interacting with TWAMP Light, or apply to all STAMP peers (see Comment for further discussion on why the current text seems internally inconsistent). In Section 4.1.1: o 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]. I think a note that which one is in use will be configured by the configuration/management function is in order. Except that the Z bit below confuses things terribly... 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. ... since, as noted by the secdir reviewer, this line just confuses everything. Either keep the "must be zero" semantics of 4656 or the "MUST match reality" semantics of 8186, but this middle case is actively harmful. (I also support Barry and Magnus' Discusses.) |
2019-09-04
|
07 | Benjamin Kaduk | [Ballot comment] Section 1 I'll note several grammar nits, inline, though perhaps some of them will not apply after the rewrite in response to the … [Ballot comment] Section 1 I'll note several grammar nits, inline, though perhaps some of them will not apply after the rewrite in response to the secdir review: Development and deployment of Two-Way Active Measurement Protocol "the Two-Way" (TWAMP) [RFC5357] and its extensions, e.g., [RFC6038] that defined features such as Reflect Octets and Symmetrical Size for TWAMP comma after TWAMP provided invaluable experience. Several independent implementations exist, have been deployed and provide important operational performance measurements. At the same time, there has been noticeable interest in using a more straightforward mechanism for active performance monitoring that can provide deterministic behavior and inherit separation of control (vendor-specific configuration or "inherit" from what? orchestration) and test functions. One of such is Performance "One such mechanism is" Measurement from IP Edge to Customer Equipment using TWAMP Light from Broadband Forum [BBF.TR-390] used as the reference TWAMP Light that, I'm not sure what the intent here is, but maybe ", which is used as the reference TWAMP Light". according to [RFC8545], includes sub-set of TWAMP-Test functions in I'd also suggest starting a new sentence for "According to [RFC8545]" (and adding the then-needed "this" and "a" for "this includes a"). combination with other applications that provide, for example, control and security. This document defines an active performance measurement test protocol, Simple Two-way Active Measurement Protocol (STAMP), that enables measurement of both one-way and round-trip performance metrics like delay, delay variation, and packet loss. I agree with the secdir reviewer that the relationship between STAMP and TWAMP Light could be much more clear. Section 2.1 MBZ May be Zero I commonly see this expand to "Must be zero"; requiring the sender to not set any bits seems more likely to preserve the ability to use the field for future extensibility, since a recipient that sees a nonzero bit knows it was consciously set (i.e., with intent to use the extension) rather than inadvertently set by someone expecting it to be ignored. (Also, if the bits are covered under the HMAC, then the recipient can't actually ignore them, since they have to be used to verify the HMAC.) Section 3 be achieved through various means. Command Line Interface, OSS/BSS (operations support system/business support system as a combination of two systems used to support a range of telecommunication services) using SNMP or controllers in Software-Defined Networking using Netconf/YANG are but a few examples. nit: if "using SNMP or controllers[...]" is supposed to be separate from "OSS/BSS", then some additional punctuation/conjunction is needed. Section 4 number. A STAMP implementation of Session-Sender MUST be able to use UDP port numbers from User, a.k.a. Registered, Ports and Dynamic, a.k.a. Private or Ephemeral, Ports ranges defined in [RFC6335]. Able to use as source, destination, or both? (We just talked about destination but not source in the previous sentence.) 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. nit: I don't see how merely "support"ing (as opposed to "require"ing or "use"ing) symmetrical packets implies these minimum packet sizes. (That is, I find the word "because" unjustified absent some statement that requires the Session-Reflector packets to be that size and a requirement for the symmetry is present.) Section 4.2 That implies that the STAMP Session-Reflector MUST keep a state for each accepted STAMP-test session, uniquely identifying STAMP- test packets to one such session instance, and enabling adding a sequence number in the test reply that is individually incremented on a per-session basis. How does it "accept a STAMP-test session"? Section 4.2.1 * in the stateful mode the Session-Reflector counts the received STAMP test packets in each test session and uses that counter to set the value of the Sequence Number field. Should we say anything about whether the initial sequence number (having received one packet from the Session-Sender) is zero or one? Section 4.2.2 Also, STAMP Session-Reflector test packet format in authenticated mode includes a key (HMAC) ([RFC2104]) hash at the end of the PDU. The detailed use of the HMAC field is in Section 4.3. nit: "keyed" Section 4.3 I think we should have a statement about HMAC key (non-)reuse across separate measurement sessions. I agree with the secdir reviewer that the confidentiality protection seems like something that would be done at a "lower" level, not a "higher" level. Section 4.4 In the former case, the Session-Sender MAY not be aware that its It's unclear that this "MAY" is normative as opposed to descriptive. Session-Reflector does not support STAMP. For example, a TWAMP Light Session-Reflector may not support the use of UDP port 862 as defined in [RFC8545]. Thus STAMP Session-Sender MAY use port numbers as defined in Section 4. If any of STAMP extensions are used, the TWAMP Light Session-Reflector will view them as Packet Padding field. The Session-Sender SHOULD use the default format for its timestamps - NTP. And it MAY use PTPv2 timestamp format. Given the above note about not knowing that the peer is TWAMP Light vs. STAMP, it seems that this SHOULD/MAY apply to all STAMP implementations, not just ones that are interacting with TWAMP Light. Which in turn might suggest that the normative statements are best made in a different section. (Also (nit), where do we say that NTP is the default format?) In the latter scenario, if a TWAMP Light Session-Sender does not support the use of UDP port 862, the test management system MUST set STAMP Session-Reflector to use UDP port number as defined in Section 4. If the TWAMP Light Session-Sender includes Packet Padding field in its transmitted packet, the STAMP Session-Reflector will return the reflected packet of the symmetrical size if the size of the received test packet is larger than the size of the STAMP base packet. The Session-Reflector MUST be set to use the default format for its timestamps, NTP. On the other hand, if we take the same approach here, and assume that the Session-Reflector may not know that the Session-Sender is TWAMP Light vs. STAMP, then this MUST would seem to always apply, and thus prevent the Session-Reflector from ever using the PTPv2 timestamp format, in which case the text related to its doing so is "dead code" and should be removed to avoid confusion. Section 8.2 RFC 2104 needs to be a normative reference. The truncation of the HMAC is simple enough that we probably don't need to consider RFC 4868 normative just for it, though. |
2019-09-04
|
07 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2019-09-04
|
07 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2019-09-04
|
07 | Warren Kumari | [Ballot comment] I'm strongly agreeing with Barry & Magnus' DISCUSSes. |
2019-09-04
|
07 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2019-09-04
|
07 | Alexey Melnikov | [Ballot comment] I am agreeing with Barry's and Magnus' DISCUSSes. |
2019-09-04
|
07 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2019-09-04
|
07 | Barry Leiba | [Ballot discuss] I'm sure this will be easy to either explain to me or re-phrase: Sections 4 and 6 both say something like "MUST be … [Ballot discuss] I'm sure this will be easy to either explain to me or re-phrase: Sections 4 and 6 both say something like "MUST be agreed by all users of the network". What does that really mean? How is it remotely possible to get agreement from all users of your network? How is it remotely possible that they could understand what you're asking them to agree to? |
2019-09-04
|
07 | Barry Leiba | [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba |
2019-09-04
|
07 | Magnus Westerlund | [Ballot discuss] Two very much discussing discusses. However, I would really like to hear the answer to these concerns before clearing. 1. Section 4.3: Is … [Ballot discuss] Two very much discussing discusses. However, I would really like to hear the answer to these concerns before clearing. 1. Section 4.3: Is the HMAC field size of 16 bytes hard coded? If there ever would exist a need to deploy another integrity solution, even if the actual algorithm used to construct the tag can be agreed by the management, there appear to exist a hard look in to use 16-byte tags. Have this issue been considered? 2. Section 6: The possible impact of the STAMP test packets on the network MUST be thoroughly analyzed, and the use of STAMP for each case MUST be agreed by all users on the network before starting the STAMP test session. I assume some potential issues are know, shouldn't they really be listed here in the security consideration to further motivate why the analysis needs to happen. |
2019-09-04
|
07 | Magnus Westerlund | [Ballot comment] 1. Section 4: Before using numbers from the User Ports range, the possible impact on the network MUST be carefully studied and … [Ballot comment] 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? |
2019-09-04
|
07 | Magnus Westerlund | [Ballot Position Update] New position, Discuss, has been recorded for Magnus Westerlund |
2019-09-03
|
07 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2019-09-03
|
07 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2019-09-03
|
07 | Amy Vezza | Telechat date has been changed to 2019-09-05 from 2019-09-19 |
2019-09-03
|
07 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2019-08-30
|
07 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2019-08-30
|
07 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-ippm-stamp-07, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-ippm-stamp-07, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2019-08-30
|
07 | Cindy Morgan | Placed on agenda for telechat - 2019-09-19 |
2019-08-30
|
07 | Mirja Kühlewind | Ballot has been issued |
2019-08-30
|
07 | Mirja Kühlewind | [Ballot Position Update] New position, Yes, has been recorded for Mirja Kühlewind |
2019-08-30
|
07 | Mirja Kühlewind | Created "Approve" ballot |
2019-08-30
|
07 | Mirja Kühlewind | Ballot writeup was changed |
2019-08-22
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joel Jaeggli |
2019-08-22
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joel Jaeggli |
2019-08-22
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dale Worley |
2019-08-22
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dale Worley |
2019-08-22
|
07 | Russ Housley | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Russ Housley. Sent review to list. |
2019-08-22
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Russ Housley |
2019-08-22
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Russ Housley |
2019-08-20
|
07 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2019-08-20
|
07 | Amy Vezza | The following Last Call announcement was sent out (ends 2019-09-03): From: The IESG To: IETF-Announce CC: ippm-chairs@ietf.org, ippm@ietf.org, Tal Mizrahi , tal.mizrahi.phd@gmail.com, … The following Last Call announcement was sent out (ends 2019-09-03): From: The IESG To: IETF-Announce CC: ippm-chairs@ietf.org, ippm@ietf.org, Tal Mizrahi , tal.mizrahi.phd@gmail.com, ietf@kuehlewind.net, draft-ietf-ippm-stamp@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Simple Two-way Active Measurement Protocol) to Proposed Standard The IESG has received a request from the IP Performance Measurement WG (ippm) to consider the following document: - 'Simple Two-way Active Measurement Protocol' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-09-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a Simple Two-way Active Measurement Protocol which enables the measurement of both one-way and round-trip performance metrics like delay, delay variation, and packet loss. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp/ballot/ No IPR declarations have been submitted directly on this I-D. |
2019-08-20
|
07 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2019-08-20
|
07 | Mirja Kühlewind | Last call was requested |
2019-08-20
|
07 | Mirja Kühlewind | Ballot approval text was generated |
2019-08-20
|
07 | Mirja Kühlewind | IESG state changed to Last Call Requested from Publication Requested |
2019-08-20
|
07 | Mirja Kühlewind | Last call announcement was generated |
2019-08-20
|
07 | Mirja Kühlewind | Ballot writeup was changed |
2019-08-12
|
07 | Greg Mirsky | New version available: draft-ietf-ippm-stamp-07.txt |
2019-08-12
|
07 | (System) | New version approved |
2019-08-12
|
07 | (System) | Request for posting confirmation emailed to previous authors: Gregory Mirsky , Henrik Nydell , Richard Foote , Guo Jun |
2019-08-12
|
07 | Greg Mirsky | Uploaded new revision |
2019-05-23
|
06 | Tommy Pauly | This shepherd writeup follows the Essay Style Document Writeup (https://www.ietf.org/chairs/document-writeups/essay-style-document-writeup/). 1. Summary The document shepherd is Tal Mizrahi, and the responsible area director … This shepherd writeup follows the Essay Style Document Writeup (https://www.ietf.org/chairs/document-writeups/essay-style-document-writeup/). 1. Summary The document shepherd is Tal Mizrahi, and the responsible area director is Mirja Kühlewind. This document describes a Simple Two-way Active Measurement Protocol (STAMP), which enables the measurement of both one-way and round-trip performance metrics like delay, delay variation, and packet loss. The intended status of this document is Standards Track, as it defines a protocol variant that continues the evolution of the Two-Way Active Measurement Protocol (TWAMP). The IPPM working group is also working on a companion draft, draft-ietf-ippm-stamp-yang, which defines a YANG data model for STAMP. This companion draft will be sent to the IESG for publication in the future. 2. Review and Consensus The draft was first submitted in October 2017, has been reviewed by a fair number of people in the IPPM working group, has had a fair number of supporters, and no objections from the working group. One of the main issues that was discussed in the context of this draft is the security considerations. The IPPM minutes from IETF 103 summarize this discussion (https://datatracker.ietf.org/meeting/103/materials/minutes-103-ippm-00). Two main questions were raised: one regarding the size of the integrity protection HMAC, and the other regarding whether encryption is required for STAMP or not. Arguments were made both ways. After IETF 103 the authors proposed the solution that is in the current draft with no objections from the working group: regarding the first issue, the HMAC is based on a SHA-256 truncated to 128 bits, and regarding the second issue, the draft does not define an encryption mechanism, but states that encryption may be provided at higher layers. Several other comments that have been raised on the mailing list have been addressed by the editors. The current version of the draft is clear, seems to have resolved all the issues, and has the consensus of the working group. 3. Intellectual Property An IPR poll was performed for this draft on the IPPM mailing list, and no related IPR disclosures have been submitted. The authors have confirmed on the mailing list that they are not aware of any related IPRs. 4. Other Points The draft does not include any requests from IANA. |
2019-05-23
|
06 | Tommy Pauly | Responsible AD changed to Mirja Kühlewind |
2019-05-23
|
06 | Tommy Pauly | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2019-05-23
|
06 | Tommy Pauly | IESG state changed to Publication Requested from I-D Exists |
2019-05-23
|
06 | Tommy Pauly | IESG process started in state Publication Requested |
2019-05-23
|
06 | Tommy Pauly | Changed consensus to Yes from Unknown |
2019-05-23
|
06 | Tommy Pauly | Intended Status changed to Proposed Standard from None |
2019-05-19
|
06 | Tal Mizrahi | This shepherd writeup follows the Essay Style Document Writeup (https://www.ietf.org/chairs/document-writeups/essay-style-document-writeup/). 1. Summary The document shepherd is Tal Mizrahi, and the responsible area director … This shepherd writeup follows the Essay Style Document Writeup (https://www.ietf.org/chairs/document-writeups/essay-style-document-writeup/). 1. Summary The document shepherd is Tal Mizrahi, and the responsible area director is Mirja Kühlewind. This document describes a Simple Two-way Active Measurement Protocol (STAMP), which enables the measurement of both one-way and round-trip performance metrics like delay, delay variation, and packet loss. The intended status of this document is Standards Track, as it defines a protocol variant that continues the evolution of the Two-Way Active Measurement Protocol (TWAMP). The IPPM working group is also working on a companion draft, draft-ietf-ippm-stamp-yang, which defines a YANG data model for STAMP. This companion draft will be sent to the IESG for publication in the future. 2. Review and Consensus The draft was first submitted in October 2017, has been reviewed by a fair number of people in the IPPM working group, has had a fair number of supporters, and no objections from the working group. One of the main issues that was discussed in the context of this draft is the security considerations. The IPPM minutes from IETF 103 summarize this discussion (https://datatracker.ietf.org/meeting/103/materials/minutes-103-ippm-00). Two main questions were raised: one regarding the size of the integrity protection HMAC, and the other regarding whether encryption is required for STAMP or not. Arguments were made both ways. After IETF 103 the authors proposed the solution that is in the current draft with no objections from the working group: regarding the first issue, the HMAC is based on a SHA-256 truncated to 128 bits, and regarding the second issue, the draft does not define an encryption mechanism, but states that encryption may be provided at higher layers. Several other comments that have been raised on the mailing list have been addressed by the editors. The current version of the draft is clear, seems to have resolved all the issues, and has the consensus of the working group. 3. Intellectual Property An IPR poll was performed for this draft on the IPPM mailing list, and no related IPR disclosures have been submitted. The authors have confirmed on the mailing list that they are not aware of any related IPRs. 4. Other Points The draft does not include any requests from IANA. |
2019-04-23
|
06 | Greg Mirsky | New version available: draft-ietf-ippm-stamp-06.txt |
2019-04-23
|
06 | (System) | New version approved |
2019-04-23
|
06 | (System) | Request for posting confirmation emailed to previous authors: Gregory Mirsky , Henrik Nydell , Richard Foote , Guo Jun |
2019-04-23
|
06 | Greg Mirsky | Uploaded new revision |
2019-03-25
|
05 | Brian Trammell | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2019-03-25
|
05 | Brian Trammell | Notification list changed to Tal Mizrahi <tal.mizrahi.phd@gmail.com> |
2019-03-25
|
05 | Brian Trammell | Document shepherd changed to Tal Mizrahi |
2019-03-01
|
05 | Brian Trammell | IETF WG state changed to In WG Last Call from WG Document |
2018-11-28
|
05 | Greg Mirsky | New version available: draft-ietf-ippm-stamp-05.txt |
2018-11-28
|
05 | (System) | New version approved |
2018-11-28
|
05 | (System) | Request for posting confirmation emailed to previous authors: Gregory Mirsky , Henrik Nydell , Richard Foote , Guo Jun |
2018-11-28
|
05 | Greg Mirsky | Uploaded new revision |
2018-11-19
|
04 | Greg Mirsky | New version available: draft-ietf-ippm-stamp-04.txt |
2018-11-19
|
04 | (System) | New version approved |
2018-11-19
|
04 | (System) | Request for posting confirmation emailed to previous authors: Gregory Mirsky , Henrik Nydell , Richard Foote , Guo Jun |
2018-11-19
|
04 | Greg Mirsky | Uploaded new revision |
2018-10-15
|
03 | Greg Mirsky | New version available: draft-ietf-ippm-stamp-03.txt |
2018-10-15
|
03 | (System) | New version approved |
2018-10-15
|
03 | (System) | Request for posting confirmation emailed to previous authors: Gregory Mirsky , Henrik Nydell , Richard Foote , Guo Jun |
2018-10-15
|
03 | Greg Mirsky | Uploaded new revision |
2018-09-07
|
02 | Greg Mirsky | New version available: draft-ietf-ippm-stamp-02.txt |
2018-09-07
|
02 | (System) | New version approved |
2018-09-07
|
02 | (System) | Request for posting confirmation emailed to previous authors: Gregory Mirsky , Henrik Nydell , Richard Foote , Guo Jun |
2018-09-07
|
02 | Greg Mirsky | Uploaded new revision |
2018-09-02
|
01 | (System) | Document has expired |
2018-03-14
|
01 | Brian Trammell | Added to session: IETF-101: ippm Tue-1550 |
2018-03-01
|
01 | Greg Mirsky | New version available: draft-ietf-ippm-stamp-01.txt |
2018-03-01
|
01 | (System) | New version approved |
2018-03-01
|
01 | (System) | Request for posting confirmation emailed to previous authors: Gregory Mirsky , Henrik Nydell , ippm-chairs@ietf.org, Guo Jun |
2018-03-01
|
01 | Greg Mirsky | Uploaded new revision |
2018-01-04
|
00 | (System) | This document now replaces draft-mirsky-ippm-stamp instead of None |
2018-01-04
|
00 | Greg Mirsky | New version available: draft-ietf-ippm-stamp-00.txt |
2018-01-04
|
00 | (System) | New version approved |
2018-01-04
|
00 | Greg Mirsky | Request for posting confirmation emailed to submitter and authors: Gregory Mirsky , Henrik Nydell , Guo Jun |
2018-01-04
|
00 | Greg Mirsky | Uploaded new revision |