Skip to main content

Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Segment Routing Networks
draft-ietf-ippm-stamp-srpm-18

Revision differences

Document history

Date Rev. By Action
2023-10-30
18 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2023-10-23
18 (System) RFC Editor state changed to AUTH48
2023-10-13
18 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2023-10-02
18 Tim Chown Request for Telechat review by INTDIR Completed: Ready. Reviewer: Tim Chown. Sent review to list.
2023-08-31
18 Juan-Carlos Zúñiga Request for Telechat review by INTDIR is assigned to Tim Chown
2023-08-16
18 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2023-08-15
18 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2023-08-15
18 (System) IANA Action state changed to In Progress from Waiting on Authors
2023-08-15
18 (System) RFC Editor state changed to EDIT
2023-08-15
18 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2023-08-15
18 (System) Announcement was received by RFC Editor
2023-08-15
18 (System) IANA Action state changed to Waiting on Authors from In Progress
2023-08-15
18 (System) IANA Action state changed to In Progress from Waiting on WGC
2023-08-15
18 (System) IANA Action state changed to Waiting on WGC from In Progress
2023-08-15
18 (System) IANA Action state changed to In Progress
2023-08-15
18 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2023-08-15
18 Cindy Morgan IESG has approved the document
2023-08-15
18 Cindy Morgan Closed "Approve" ballot
2023-08-15
18 Cindy Morgan Ballot approval text was generated
2023-08-15
18 Cindy Morgan Ballot writeup was changed
2023-08-15
18 (System) Removed all action holders (IESG state changed)
2023-08-15
18 Martin Duke IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2023-08-15
18 John Scudder [Ballot comment]
Thanks for addressing my Discuss and comments.
2023-08-15
18 John Scudder [Ballot Position Update] Position for John Scudder has been changed to No Objection from Discuss
2023-08-04
18 Lars Eggert
[Ballot comment]
# GEN AD review of draft-ietf-ippm-stamp-srpm-17

CC @larseggert

Thanks to Joel Halpern for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/crZp5rrOYaDNMcoM95b5pFQBReo). …
[Ballot comment]
# GEN AD review of draft-ietf-ippm-stamp-srpm-17

CC @larseggert

Thanks to Joel Halpern for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/crZp5rrOYaDNMcoM95b5pFQBReo).

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Outdated references

Document references `draft-ietf-ippm-stamp-on-lag-01`, but `-03` is the latest
available revision.

### Grammar/style

#### Section 3, paragraph 4
```
s field in octets. The length is 4 octet for IPv4 address and 16 octet for I
                                  ^^^^^
```
Possible agreement error. The noun "octet" seems to be countable.

#### Section 3, paragraph 4
```
is 4 octet for IPv4 address and 16 octet for IPv6 address. The Destination
                                    ^^^^^
```
Possible agreement error. The noun "octet" seems to be countable.

#### Section 4.1, paragraph 4
```
bit): Reply Request Flag at bit 31 (least significant bit) is defined as fol
                                    ^^^^^
```
A determiner may be missing.

#### Section 4.1.2, paragraph 3
```
s field in octets. The length is 4 octet for IPv4 address and 16 octet for I
                                  ^^^^^
```
Possible agreement error. The noun "octet" seems to be countable.

#### Section 4.1.2, paragraph 3
```
h is 4 octet for IPv4 address and 16 octet for IPv6 address. 4.1.3. Return Se
                                    ^^^^^
```
Possible agreement error. The noun "octet" seems to be countable.

#### Section 4.1.3, paragraph 14
```
re two possible combinations for such a interoperability use case: - STAMP S
                                      ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 6, paragraph 4
```
e allocated according to the "First Come First Served" procedure as specifie
                                    ^^^^
```
It seems that a comma is missing. (Also elsewhere.)

#### Section 8.1, paragraph 3
```
flow-label, etc. from the packet. Hence for IPv4, for example, different va
                                  ^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Hence".

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool
2023-08-04
18 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss
2023-08-04
18 Rakesh Gandhi New version available: draft-ietf-ippm-stamp-srpm-18.txt
2023-08-04
18 Rakesh Gandhi New version accepted (logged-in submitter: Rakesh Gandhi)
2023-08-04
18 Rakesh Gandhi Uploaded new revision
2023-08-04
17 Lars Eggert
[Ballot discuss]
# GEN AD review of draft-ietf-ippm-stamp-srpm-17

CC @larseggert

Thanks to Joel Halpern for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/crZp5rrOYaDNMcoM95b5pFQBReo). …
[Ballot discuss]
# GEN AD review of draft-ietf-ippm-stamp-srpm-17

CC @larseggert

Thanks to Joel Halpern for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/crZp5rrOYaDNMcoM95b5pFQBReo).

## Discuss

Two issues that I think will be quick to fix:

### Section 4, paragraph 12
```
    other Return Path TLVs if present.  A Session-Reflector that supports
    this TLV MUST reply using the Return Path received in the Session-
    Sender test packet, if possible.
```
"MUST ... if possible" is an odd construction. Please rephrase and
clarify the requirements level.

### Section 4.1.3, paragraph 16
```
    The SRv6 Segment List contains a list of 128-bit IPv6 addresses
    representing the SRv6 SIDs.  Length of the Sub-TLV modulo MUST be 0.
```
Modulo *what*?
2023-08-04
17 Lars Eggert
[Ballot comment]
## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore …
[Ballot comment]
## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Outdated references

Document references `draft-ietf-ippm-stamp-on-lag-01`, but `-03` is the latest
available revision.

### Grammar/style

#### Section 3, paragraph 4
```
s field in octets. The length is 4 octet for IPv4 address and 16 octet for I
                                  ^^^^^
```
Possible agreement error. The noun "octet" seems to be countable.

#### Section 3, paragraph 4
```
is 4 octet for IPv4 address and 16 octet for IPv6 address. The Destination
                                    ^^^^^
```
Possible agreement error. The noun "octet" seems to be countable.

#### Section 4.1, paragraph 4
```
bit): Reply Request Flag at bit 31 (least significant bit) is defined as fol
                                    ^^^^^
```
A determiner may be missing.

#### Section 4.1.2, paragraph 3
```
s field in octets. The length is 4 octet for IPv4 address and 16 octet for I
                                  ^^^^^
```
Possible agreement error. The noun "octet" seems to be countable.

#### Section 4.1.2, paragraph 3
```
h is 4 octet for IPv4 address and 16 octet for IPv6 address. 4.1.3. Return Se
                                    ^^^^^
```
Possible agreement error. The noun "octet" seems to be countable.

#### Section 4.1.3, paragraph 14
```
re two possible combinations for such a interoperability use case: - STAMP S
                                      ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 6, paragraph 4
```
e allocated according to the "First Come First Served" procedure as specifie
                                    ^^^^
```
It seems that a comma is missing. (Also elsewhere.)

#### Section 8.1, paragraph 3
```
flow-label, etc. from the packet. Hence for IPv4, for example, different va
                                  ^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Hence".

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool
2023-08-04
17 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded for Lars Eggert
2023-07-25
17 Rakesh Gandhi New version available: draft-ietf-ippm-stamp-srpm-17.txt
2023-07-25
17 Rakesh Gandhi New version accepted (logged-in submitter: Rakesh Gandhi)
2023-07-25
17 Rakesh Gandhi Uploaded new revision
2023-07-10
16 Warren Kumari
[Ballot comment]
I still don't love this document, but I do think that it is sufficiently improved that I'm (somewhat reluctantly) removing my DISCUSS.
I …
[Ballot comment]
I still don't love this document, but I do think that it is sufficiently improved that I'm (somewhat reluctantly) removing my DISCUSS.
I do still support the authors addressing John Scudder's DISCUSS...
2023-07-10
16 Warren Kumari [Ballot Position Update] Position for Warren Kumari has been changed to No Objection from Discuss
2023-07-07
16 Murray Kucherawy Ballot comment text updated for Murray Kucherawy
2023-07-06
16 Andrew Alston [Ballot Position Update] New position, Abstain, has been recorded for Andrew Alston
2023-07-06
16 Rakesh Gandhi New version available: draft-ietf-ippm-stamp-srpm-16.txt
2023-07-06
16 Rakesh Gandhi New version accepted (logged-in submitter: Rakesh Gandhi)
2023-07-06
16 Rakesh Gandhi Uploaded new revision
2023-06-29
15 John Scudder
[Ballot discuss]
Thanks for your work to address my previous DISCUSS and COMMENTs. Although you've worked to remove the reliance of "Limited Domain" (thank you), …
[Ballot discuss]
Thanks for your work to address my previous DISCUSS and COMMENTs. Although you've worked to remove the reliance of "Limited Domain" (thank you), regrettably the new text introduces a new, and I think also problematic, reliance on the SR Domain concept. To quote from my earlier email,

On Jun 22, 2023, at 1:09 PM, John Scudder  wrote:

In looking over the new version, it occurred to me that although the document is called “... for Segment Routing Networks” and although that was the use case that motivated it, the only elements whose applicability actually is limited to SR are the Return Path SR-MPLS Segment-List Sub-TLV and the Return Path SRv6 Segment-List Sub-TLV. All the rest are generically applicable. This is basically a good thing IMO — one likes to see specs whose applicability is greater than just the use case that led to their development — but it does mean that "The usage of STAMP protocol is intended for deployment in SR domains [RFC8402]” isn't sufficient, I’m afraid — whether the use case that led to the development was restricted to SR or not, one can easily see how (for example) a Return Address Sub-TLV could be used outside of an SR deployment. That use might be by design, or it might be by an attacker.

To repeat the concern in different words: You’ve rewritten the first paragraph of the Security Considerations as

  The usage of STAMP extensions defined in this document is intended
  for deployment in SR domains [RFC8402].  It is assumed that a node
  involved in STAMP protocol operation has previously verified the
  integrity of the path and the identity of the far-end Session-
  Reflector.

This eliminates the reliance on the Limited Domains RFC (good) but you’re improperly (I think) assuming that you can rely on the SR domain definition instead. This is still true even though you changed “STAMP protocol” (the version I commented on in the quote above) to “STAMP extensions”. Again, to repeat: I don’t think it’s either reasonable or desirable to restrict the extensions you’ve defined to be only for use in an SR domain, and therefore, I think the SecCons can’t rest on the foundation of the SR document set. If you did want to rest on that foundation, I think you would have to be much more prescriptive about saying the extensions MUST NOT be processed other than in an SR context (that’s probably not the right wording) — but I think that would be undesirable, and I think if you did want to make that change, it would be a pretty fundamental change requiring a new WGLC.
2023-06-29
15 John Scudder Ballot comment and discuss text updated for John Scudder
2023-06-22
15 (System) Changed action holders to Martin Duke (IESG state changed)
2023-06-22
15 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2023-06-22
15 Rakesh Gandhi New version available: draft-ietf-ippm-stamp-srpm-15.txt
2023-06-22
15 Rakesh Gandhi New version accepted (logged-in submitter: Rakesh Gandhi)
2023-06-22
15 Rakesh Gandhi Uploaded new revision
2023-06-22
14 Kathleen Moriarty Request for Telechat review by SECDIR Completed: Ready. Reviewer: Kathleen Moriarty. Sent review to list.
2023-06-22
14 (System) Changed action holders to Rakesh Gandhi, Clarence Filsfils, Dan Voyer, Mach Chen, Bart Janssens, Richard Foote, Martin Duke (IESG state changed)
2023-06-22
14 Amy Vezza IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2023-06-22
14 Warren Kumari
[Ballot discuss]
I am balloting DISCUSS on this document because I do not believe the the document fully specifies the processing and behavior. It is …
[Ballot discuss]
I am balloting DISCUSS on this document because I do not believe the the document fully specifies the processing and behavior. It is sufficiently unclear in many places that I believe that it is not fully implementable by people not involved in its creation. Note that this was originally an Abstain, but on further consideration I feel it requires a DISCUSS.

There are many examples of this, especially around the source and destination address text.

For example:
"The Session-Sender may need to transmit test packets to the Session-Reflector with a different destination address that is not matching an address of the Session-Reflector e.g. when the STAMP test packet is encapsulated by a tunneling protocol e.g., encapsulated with an SR-MPLS Segment List and IPv4 header containing destination IPv4 address from 127/8 range or encapsulated with outer IPv6 header and Segment Routing Header (SRH) with inner IPv6 header containing IPv6 destination IPv6 address ::1/128." - I'm unable to parse this / how this is expected to work. If the sender sends packets to the reflector through a tunnel, isn't the packet decapsulated when it leaves the tunnel / link, and then the address should be that of the SR? Or are you saying that this is a function of the decapsulation, and whatever process does that should simply trust and process any STAMP packets, regardless of it if owns the address?
It is also very unclear what exactly the behavior is intended to be for nodes when using "different values of IPv4 destination address from 127/8 range may be used in the IPv4 header to measure different ECMP paths." - is the assumption that the Session-Reflector is listening on / will process any decapsulated packet destined to any address in 127/8? If so, that is really not clear.

This text is also unclear: "For security reasons (e.g., to avoid node discovery), the Session-Reflector SHOULD use the received Destination Node Address as the Source Address in the IP header of the reply test packet only if the Destination Node Address is one of the addresses on the node, instead of using its Node Address." - this sounds like a node should extract the packet, and use the received Destination Node Address as the Source Address if this address exists on the node. If this correct? If so, this is overriding the standard source address selection logic on the device, and can be used to cause packets to be emitted which bypass firewall filters (e.g: My management network is numbered out of 10/8, and I have firewall filters which only allow access to 10/8 from bastion stations. By using the described solution, I can send a STAMP packet to the node and set the Destination Node Address as 10.0.0.5 (an address on the device). This specifies that the Source Address of the return packet should be 10.0.0.5, regardless of if the packet is received on or processed by that interface. This allows filters which match on source address to be bypassed.) It is also unclear what you mean by "e.g., to avoid node discovery".

There is much in this document which is underspecified or hand-wavey, and, as such, I do not think that I can ballot No Objection in good faith.
2023-06-22
14 Warren Kumari [Ballot Position Update] Position for Warren Kumari has been changed to Discuss from Abstain
2023-06-22
14 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2023-06-22
14 Rakesh Gandhi New version available: draft-ietf-ippm-stamp-srpm-14.txt
2023-06-22
14 Rakesh Gandhi New version accepted (logged-in submitter: Rakesh Gandhi)
2023-06-22
14 Rakesh Gandhi Uploaded new revision
2023-06-22
13 Murray Kucherawy
[Ballot comment]
The term "PM" is defined in Section 2.2, but is only used in the Introduction.  It could probably be dropped.  Similarly, "SRH" is …
[Ballot comment]
The term "PM" is defined in Section 2.2, but is only used in the Introduction.  It could probably be dropped.  Similarly, "SRH" is defined but has only a single use in Section 3.
2023-06-22
13 Murray Kucherawy Ballot comment text updated for Murray Kucherawy
2023-06-21
13 Warren Kumari
[Ballot comment]
I am balloting Abstain on this document because I do not believe the the document fully specifies the processing and behavior. It is …
[Ballot comment]
I am balloting Abstain on this document because I do not believe the the document fully specifies the processing and behavior. It is sufficiently unclear in many places that I believe that it is not fully implementable by people not involved in its creation.

There are many examples of this, especially around the source and destination address text.

For example:
"The Session-Sender may need to transmit test packets to the Session-Reflector with a different destination address that is not matching an address of the Session-Reflector e.g. when the STAMP test packet is encapsulated by a tunneling protocol e.g., encapsulated with an SR-MPLS Segment List and IPv4 header containing destination IPv4 address from 127/8 range or encapsulated with outer IPv6 header and Segment Routing Header (SRH) with inner IPv6 header containing IPv6 destination IPv6 address ::1/128." - I'm unable to parse this / how this is expected to work. If the sender sends packets to the reflector through a tunnel, isn't the packet decapsulated when it leaves the tunnel / link, and then the address should be that of the SR? Or are you saying that this is a function of the decapsulation, and whatever process does that should simply trust and process any STAMP packets, regardless of it if owns the address?
It is also very unclear what exactly the behavior is intended to be for nodes when using "different values of IPv4 destination address from 127/8 range may be used in the IPv4 header to measure different ECMP paths." - is the assumption that the Session-Reflector is listening on / will process any decapsulated packet destined to any address in 127/8? If so, that is really not clear.

This text is also unclear: "For security reasons (e.g., to avoid node discovery), the Session-Reflector SHOULD use the received Destination Node Address as the Source Address in the IP header of the reply test packet only if the Destination Node Address is one of the addresses on the node, instead of using its Node Address." - this sounds like a node should extract the packet, and use the received Destination Node Address as the Source Address if this address exists on the node. If this correct? If so, this is overriding the standard source address selection logic on the device, and can be used to cause packets to be emitted which bypass firewall filters (e.g: My management network is numbered out of 10/8, and I have firewall filters which only allow access to 10/8 from bastion stations. By using the described solution, I can send a STAMP packet to the node and set the Destination Node Address as 10.0.0.5 (an address on the device). This specifies that the Source Address of the return packet should be 10.0.0.5, regardless of if the packet is received on or processed by that interface. This allows filters which match on source address to be bypassed.) It is also unclear what you mean by "e.g., to avoid node discovery".

There is much in this document which is underspecified or hand-wavey, and, as such, I do not think that I can ballot No Objection in good faith.
2023-06-21
13 Warren Kumari [Ballot Position Update] New position, Abstain, has been recorded for Warren Kumari
2023-06-21
13 Roman Danyliw
[Ballot comment]
Thank you to Kathleen Moriarty for the SECDIR review.

I support John Scudder’s DISCUSS position.  His ballot highlights the areas of the Security …
[Ballot comment]
Thank you to Kathleen Moriarty for the SECDIR review.

I support John Scudder’s DISCUSS position.  His ballot highlights the areas of the Security Considerations that would benefit from further polish.  Additional comments on it are noted below.

** Section 3.  Editorial.
  e.g. when the STAMP test packet
  is encapsulated by a tunneling protocol e.g., encapsulated with an
  SR-MPLS Segment List and IPv4 header containing destination IPv4
  address from 127/8 range or encapsulated with outer IPv6 header and
  Segment Routing Header (SRH) with inner IPv6 header containing IPv6
  destination IPv6 address ::1/128.

The use of the double “e.g.” confusing as to whether there are two example here, or the second “e.g.” is a more specific instance of the first “e.g.”.

** Section 3.
  Hence for IPv4, for
  example, different values of IPv4 destination address from 127/8
  range may be used in the IPv4 header to measure different ECMP paths.

Can this guidance please be clarified.
-- Is “127/8” referring to an RFC5735 special use address block of “127.0.0.0/8”?

-- Where is this loopback address being used?

-- Is this text suggesting that a loopback address be in some way where it is transmitted from the end-device?

** Section 4.  Editorial.
  Return Path Sub-TLVs : As defined in Section 5.1.

This text should reference Section 4.1.

** Section 5.  Typo. s/desctibed/described/

** Section 6.
  If desired, attacks can be mitigated by performing basic validation
  and sanity checks, at the Session-Sender, of the timestamp fields in
  received reply test packets.

Could this text be clearer on what attack is being mitigated and what “basic validation and sanity check” means.  Is this referencing a replay attack?  What are reasonable parameters for the timestamp check?

** Section 6.  In the spirit of inclusive language, consider alternatives to “man-in-the-middle”.

** Section 6.

  The STAMP extensions defined in this document may be used for
  potential "proxying" attacks.

Is this use of “proxying” a STAMP specific term?  My experience is that this is called address spoofing.  Commonly there is a discussion about the amplification factor when discussing reflection style attacks

** Section 6.
  But normally, such attacks will not happen in an
  SR domain where the Session-Senders and Session-Reflectors belong to
  the same domain.

-- Why wouldn’t such an attack happen in the “same domain”?

-- Is the SR domain the same as the “STAMP domain”?

** Section 6.
  The
  Session-Reflector may drop the Session-Sender test packet when it
  cannot determine whether the Return Path has the destination to the
  Session-Sender.

For the purposes of collecting metrics, this advice makes sense.  However, in the context of a DDoS attack hasn’t the damage been done.  The packet has already arrived at the target.  Can the utility of this drop action be clarified?
2023-06-21
13 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2023-06-20
13 John Scudder
[Ballot discuss]
# John Scudder, RTG AD, comments for draft-ietf-ippm-stamp-srpm-13
CC @jgscudder

Thanks for this document. Despite the lengthiness of my ballot and DISCUSS section, …
[Ballot discuss]
# John Scudder, RTG AD, comments for draft-ietf-ippm-stamp-srpm-13
CC @jgscudder

Thanks for this document. Despite the lengthiness of my ballot and DISCUSS section, I think this document is in reasonably good shape and will be ready to go after one more good editing pass. Thanks for your work on it, and thanks in advance for helping me work through my DISCUSS points.

## DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion on the following topics:

### Section 3, not an address of the Session-Reflector, really?

The description "transmit test packets to the Session-Reflector with a different destination address that is not matching an address of the Session-Reflector" appears to be inaccurate, at least for the use case you've presented: loopback is by definition an address of the Session-Reflector, and indeed of every IP-enabled node, is it not? So it's not right to say that the DA is "not matching an address of the Session-Reflector".

As far as I can tell by skimming the STAMP base spec, STAMP is basically a host function. Presumably any packet whose DA was not an address of the Session-Reflector wouldn't be delivered to the host stack, and consequently wouldn't be processed. So it seems that perhaps this functionality is only for use when the DA is set to loopback. Is that correct?

Is the entire effect of the Destination Node Address TLV to tell the target what SA to use in its reply, and for session identification (although the latter appears to be an inessential use since SSID would do the same job)?

Once I have more confidence I understand what's really going on here, I may have some further suggestions for how to edit for clarity. According to my current understanding, it seems to me as though something along the lines of "The Session-Sender may need to transmit test packets to an address of the Session-Reflector which is not suitable for use as the Source Address of the reply test packet. This TLV allows the Session-Sender to request the Session-Reflector to use a different Source Address in its reply test packet" might work.

### Section 6, "limited domain"

I'm concerned with the reliance on "limited domain" without doing the work to define what's meant.

  The usage of STAMP protocol is intended for deployment in limited
  domains [RFC8799].
 
RFC 8762 doesn't indicate this, or at least, it has no mention of such in its Security Considerations section nor occurrence of the string "limited" anywhere in the RFC. Further, RFC 8799 isn't a good reference. It's not an IETF document and doesn't itself claim to define what a limited domain is. From the RFC 8799 abstract: "Finally, it shows the need for a precise definition of "limited domain membership"". That is, it identifies the need for a definition but doesn't claim to supply one. RFC 8799 does provide, in Section 6, some guidance that might be helpful in defining what is meant by a "limited domain" in a specific context -- but it is up to the document defining that context, to define what it means by "limited domain". Some of the underlying STAMP documents do provide context about their assumptions of the deployment environment which might broadly speaking fit the "limited domain" rubric -- but they do so in specific terms.

It's regrettable that the IETF has no document that defines "limited domain", but the fact remains that we don't.

This deficiency might not be problematic except that you lean on it quite heavily in the last paragraph of the section:

  The STAMP extensions defined in this document may be used for
  potential "proxying" attacks.  For example, a Session-Sender may
  specify a return path that has a destination different from that of
  the Session-Sender.  But normally, such attacks will not happen in an
  SR domain where the Session-Senders and Session-Reflectors belong to
  the same domain.
 
The "but normally" sentence really cries out for some more precise definition of what you think the security context is. Maybe there is a reference within the STAMP or SR document set that you can reference to provide this context, but RFC 8799 is not sufficient.
2023-06-20
13 John Scudder
[Ballot comment]
## COMMENTS

### Section 3, run-on

(It may not be worth putting much effort into this, and the other Section 3 COMMENTs, until …
[Ballot comment]
## COMMENTS

### Section 3, run-on

(It may not be worth putting much effort into this, and the other Section 3 COMMENTs, until we've converged on my Section 3 DISCUSS question.)

The first paragraph is a run-on sentence. Please consider breaking it up for clarity and readability:

  The Session-Sender may need to transmit test packets to the Session-
  Reflector with a different destination address that is not matching
  an address of the Session-Reflector e.g. when the STAMP test packet
  is encapsulated by a tunneling protocol e.g., encapsulated with an
  SR-MPLS Segment List and IPv4 header containing destination IPv4
  address from 127/8 range or encapsulated with outer IPv6 header and
  Segment Routing Header (SRH) with inner IPv6 header containing IPv6
  destination IPv6 address ::1/128.

A good first step would be to make each example its own sentence.

### Section 3, re-specifying RFC 8972

  The Destination Node Address TLV is optional.  The Destination Node
  Address TLV indicates the address of the intended Session-Reflector
  node of the test packet.  The Destination Node Address is also used
  to uniquely identify the STAMP session on the Session-Reflector when
  the optional SSID is not sent.  For security reasons (e.g., to avoid
  node discovery), the Session-Reflector SHOULD use the received
  Destination Node Address as the Source Address in the IP header of
  the reply test packet only if the Destination Node Address is one of
  the addresses on the node, instead of using its Node Address.  The
  Session-Reflector MUST add the received Destination Node Address TLV
  in the reply test packet to ensure the symmetric reply test packet
  size and to transmit the STAMP TLV Flags to the Session-Sender.

A minor comment, "The Session-Reflector MUST add the received Destination Node Address TLV in the reply" should be "The Session-Reflector MUST add the received Destination Node Address TLV, if any, in the reply", right? Because this is an optional TLV?

But a more important point is that much of this paragraph is unneeded since it repeats requirements of the underlying specifications. According to the base specs, all TLVs are optional, so it's unnecessary to say so. Similarly, according to RFC 8792, received TLVs have to be sent back in the reply, so it's unnecessary to say that. It's preferable not to respecify things that have already been specified, so I suggest deleting it.

Next, I'm concerned about the "for security reasons" sentence. First, I don't know what "node discovery" means. Can you explain? Second, I actually don't know what this sentence is telling me, even if I ignore the parenthetical. I think *maybe* it's something like "if the received Destination Node Address is one of the addresses of the Session-Reflector, it SHOULD be used as the Source Address in the IP header of the reply test packet." Is that right?

If so, perhaps something like,

NEW:
  The Destination Node Address TLV indicates an address of the
  intended Session-Reflector node of the test packet.  The Destination
  Node Address is also used to uniquely identify the STAMP session on
  the Session-Reflector when the optional SSID is not sent.  If the
  received Destination Node Address is one of the addresses of the
  Session-Reflector, it SHOULD be used as the Source Address in the IP
  header of the reply test packet.

### Section 3, U flag technically violates 8972

Finally, I note that this spec's use of the U flag, for example

  A Session-Reflector that recognizes this TLV, MUST set the U flag
  [RFC8972] in the reply test packet to 1 if the Session-Reflector
  determined that it is not the intended Destination as identified in
  the Destination Node Address TLV.

does not seem to be strictly compliant with how RFC 8972 specifies the flag: "A Session-Reflector MUST set the U flag to 1 if the Session-Reflector has not understood the TLV. Otherwise, the Session-Reflector MUST set the U flag in the reflected packet to 0." But, I suppose we could split hairs about what it means to "understand" a TLV. In any case, as far as I can tell the nominal violation of RFC 8972 seems harmless, but I wanted to flag this in case it raises a concern I'm not seeing.

### Section 4, incorrect xref

  Return Path Sub-TLVs : As defined in Section 5.1.

You mean Section 4.1. I assume you hard-coded the "5.1" -- if you use the anchor attribute in your section element, and then reference that with an xref element, then you'll never have these kinds of errors.

### Section 4, missing "for"

                                                    In the case of
  promiscuous operation, the Stateless Session-Reflector will require
  an indication of how to return the test packet on a specific path,
  for example, measurement in an ECMP environment.
 
That should be "for example, for measurement", right?

### Section 4, re-specifying RFC 8972

  The Return Path TLV is optional.  The Session-Sender MUST only insert
  one Return Path TLV in the STAMP test packet. 
 
Should be "MUST insert at most one" or "MUST NOT insert more than one", right? The way you've written it, the first sentence says it's optional, and the second one says it's not optional. :-(

                                                  The Session-Reflector
  that supports this TLV, MUST only process the first Return Path TLV
  in the test packet and ignore other Return Path TLVs if present,
 
The following again is re-specifying what is already specified in RFC 8972:

                                                                    and
  it MUST add the received Return Path TLV (including all Sub-TLVs) in
  the reply test packet to ensure the symmetric reply test packet size
  and to transmit the STAMP TLV Flags to the Session-Sender. 
 
I think you should delete it.
 
                                                              The
  Session-Reflector that supports this TLV MUST reply using the Return
  Path received in the Session-Sender test packet. 
 
And again here:

                                                    In the case where
  the Session-Reflector does not support this TLV, the procedure
  defined in [RFC8762] is followed by the Session-Reflector.

Again, no need to say "please follow the base spec", it should be a given. Putting all that together, perhaps,

NEW:
  A Session-Sender MUST NOT insert more than one Return Path TLV in the
  STAMP test packet.  A Session-Reflector that supports this TLV MUST
  only process the first Return Path TLV in the test packet and ignore
  other Return Path TLVs if present.  A Session-Reflector that supports
  this TLV MUST reply using the Return Path received in the
  Session-Sender test packet, if possible.

### Section 4, U flag indicates inability to use Return Path

  A Session-Reflector that recognizes this TLV, MUST set the U flag
  [RFC8972] in the reply test packet to 1 if the Session-Reflector
  determined that it cannot use the return path in the test packet to
  transmit the reply test packet.  Otherwise, the Session-Reflector
  MUST set the U flag in the reply test packet to 0.

The same comment applies about this being a technical violation of RFC 8972's definition of the U flag. But more importantly, it reminds us that it might not be possible for the Session-Reflector to honor the Return Path TLV, which is why I suggested the "if possible" in my previous comment.

### Section 4.1, redundant with Section 4

This text:

  When the Return Path Sub-TLV is present in the Session-Sender test
  packet, the Session-Reflector that supports this TLV, MUST transmit
  the reply test packet using the return path information specified in
  the Return Path Sub-TLV.

seems like it's redundant with this from Section 4:

                                                              The
  Session-Reflector that supports this TLV MUST reply using the Return
  Path received in the Session-Sender test packet.
 
If there is actually a need for both, please explain the difference? Otherwise, I suggest removing the quoted 4.1 text. Also, if both are actually needed, isn't there also a need for text talking about what happens if the Return Path cannot be followed?

### Section 4.1, re-specifying RFC 8972

  Any extra Return Path Sub-TLV not procesed by the Session-Reflector
  is returned to the Session-Sender in reply test packet with U flag
  set to 1.

This, again, seems unnecessary and I'd cut it, but at least in this one you haven't used any RFC 2119 keywords so it's less harmful. (Also, if you do retain the text, "procesed" is a typo, should be "processed".)

### Section 4.1.1, editing error?

  The format of the Return Path Control Code Sub-TLV is shown in
  Figure 3.  The Type of the Return Path Control Code Sub-TLV is
  defined as following:

Looks like the second sentence is an editing error/leftover? Should it be,

NEW:
  The format of the Return Path Control Code Sub-TLV is shown in
  Figure 3. 

### Section 4.1.2, this sentence makes no sense

  The STAMP reply test packet may be transmitted to the Session-Sender
  to a different destination address on the Session-Sender using Return
  Path TLV.
 
Can you clean up the wording, please? I would propose an edit but I can't make sense of the sentence.

### Section 4.1.2, another potential deletion

                                                When transmitting the
  STAMP test packet to a different destination address, the Session-
  Sender MUST follow the procedure defined in Section 4.3 of [RFC8762].

First, when you say "different destination address", do you mean different from the SA in the received packet, or different from the address in the Return Address Sub-TLV?

Second, aren't the procedures of Section 4.3 of RFC 8762 *always* to be followed by the Session-Reflector? Shouldn't this sentence simply be deleted for the same reason as I've suggested other deletions?

### Section 4.1.2, wording

  The Return Address is the Destination Address of the Session-
  Reflector reply test packet and is different than the Source Address
  in the Session-Sender test packet.

Would it be accurate to re-word this as,

  The Return Address requests that the Session-Reflector reply test packet
  be sent to the specified address, rather than to the Source Address in
  the Session-Sender test packet.
 
The specific wording that bugged me was "is different than" -- it's semantically different, but I presume there's no actual prohibition/prevention of a sender placing the same address in both the SA and the Return Address, so this statement isn't necessarily true as written.

### Section 4.1.3.1, wording

  An SR-MPLS Label Stack Sub-TLV may carry only the Binding SID Label
  [I-D.ietf-pce-binding-label-sid] of the Return SR-MPLS Policy.  The
  Binding SID Label of the Return SR-MPLS Policy is known at the
  Session-Reflector.  The mechanism to signal the Binding SID Label to
  the Session-Sender is outside the scope of this document.

I guess the "may" above is used in the sense of "might" or "could". I suggest you replace it with one of those, it's confusing otherwise, the more so because of the common use of MAY in IETF documents to indicate something different

Also, instead of "is known at" I suggest "is local to"; as written the sentence isn't necessarily true, is it?

  An SR-MPLS Label Stack Sub-TLV may also include the Path Segment
  Identifier Label of the Return SR-MPLS Policy in the Segment List of
  the SR-MPLS Policy.

This is again, "might" or "could", right? And these two paragraphs are not meant to be exhaustive or limiting?

### Section 4.1.3.2, wording

The comments I made on 4.1.3.1 apply here as well.

### Section 6, MITM is outmoded

Note that "man-in-the-middle" is a somewhat dated term, consider something like "on-path".

### Section 6, "may drop"

                    In order to prevent using the extension defined in
  this document for proxying any possible attacks, the return path has
  destination to the same node where the forward path is from.  The
  Session-Reflector may drop the Session-Sender test packet when it
  cannot determine whether the Return Path has the destination to the
  Session-Sender.  That means, the Session-Sender should choose a
  proper source address according to the specified Return Path to help
  the Session-Reflector to make that decision.

In "may drop" do you mean "MAY drop"? Perhaps use the RFC 2119 keyword if so.

Can you describe a specific mechanism by which a Session-Reflector might actually make this determination? As written, the text places a lot of responsibility on the implementor to "do... something" without providing more than the barest clue as to what the "something" is.

Also, the second clause of the first sentence is malformed. I mentally corrected it to "the return path must be destined to the node from which the forward path originated". If this is what you mean, I suggest some update to the wording. If this is not what you meant, please help me understand.

### Section 7, values 0 and 255

What about values 0 and 255 in the Return Path Sub-TLV Type Registry? I see you allocate them in Table 3, but it's a little odd to not specify the allocation policy for these, even though you do cover types 1-4 (also allocated in Table 3) under the 1-175 range.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
2023-06-20
13 John Scudder [Ballot Position Update] New position, Discuss, has been recorded for John Scudder
2023-06-20
13 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2023-06-19
13 Erik Kline
[Ballot comment]
# Internet AD comments for draft-ietf-ippm-stamp-srpm-13
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments …
[Ballot comment]
# Internet AD comments for draft-ietf-ippm-stamp-srpm-13
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S4.1.3.1

* Might be worth saying that Length modulo 4 MUST be 0.

### S4.1.3.2

* Might be worth saying that Length modulo 16 MUST be 0.
2023-06-19
13 Erik Kline Ballot comment text updated for Erik Kline
2023-06-19
13 Erik Kline
[Ballot comment]
# Internet AD comments for draft-ietf-ippm-stamp-srpm-13
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments …
[Ballot comment]
# Internet AD comments for draft-ietf-ippm-stamp-srpm-13
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S4.1.3.1

* Might we worth saying that Length modulo 4 MUST be 0.

### S4.1.3.2

* Might we worth saying that Length modulo 16 MUST be 0.
2023-06-19
13 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2023-06-19
13 Éric Vyncke
[Ballot comment]
# Éric Vyncke, INT AD, comments for draft-ietf-ippm-stamp-srpm-12

Thank you for the work put into this document and for addressing my previous DISCUSS …
[Ballot comment]
# Éric Vyncke, INT AD, comments for draft-ietf-ippm-stamp-srpm-12

Thank you for the work put into this document and for addressing my previous DISCUSS & COMMENT points (see https://mailarchive.ietf.org/arch/msg/ippm/1yKoMYbp-idQ53v09WGnKy-BNuE/)

Special thanks to Tommy Pauly for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric
2023-06-19
13 Éric Vyncke [Ballot Position Update] Position for Éric Vyncke has been changed to No Objection from Discuss
2023-06-19
13 Rakesh Gandhi New version available: draft-ietf-ippm-stamp-srpm-13.txt
2023-06-19
13 Rakesh Gandhi New version accepted (logged-in submitter: Rakesh Gandhi)
2023-06-19
13 Rakesh Gandhi Uploaded new revision
2023-06-19
12 Jim Guichard
[Ballot comment]
=== Comments ===

- Section 2.1 - please update this section and use the boilerplate text from RFC 8174.

- Section 2.2 …
[Ballot comment]
=== Comments ===

- Section 2.1 - please update this section and use the boilerplate text from RFC 8174.

- Section 2.2 - SID: Segment ID. To make this consistent with other documents this should probably read 'SID: Segment Identifier'.

- Section 2.2 - SL: Segment List. RFC8402 uses the abbreviation SL to mean 'Segments Left' so to avoid confusion with other documents I would suggest using a different abbreviation here for Segment List or do not use an abbreviation at all and simply use 'Segment List' throughout the text of the document.

- Section 3 - '[RFC8972] defines STAMP test packets that can include one or more optional TLVs.'. RFC8972 says that STAMP defines two different test packet formats: one for packets transmitted by the STAMP Session-Sender and one for packets transmitted by the STAMP Session-Reflector. Does the quoted sentence apply to both (I assume that it does)? please make that clear in the text.
2023-06-19
12 Jim Guichard [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard
2023-06-19
12 Robert Wilton
[Ballot comment]
Hi,

Thanks for this document.

As one potential minor nit, I found the description for the segments in "4.1.3.1.  Return Path SR-MPLS Segment-List …
[Ballot comment]
Hi,

Thanks for this document.

As one potential minor nit, I found the description for the segments in "4.1.3.1.  Return Path SR-MPLS Segment-List Sub-TLV" to be more clear/explicit than "4.1.3.2.  Return Path SRv6 Segment-List Sub-TLV".  Hence, maybe it would be worth adding a sentence to 4.2.3.2 to be explicit about what Segment(1) represents, and what size it is, or use "Segment List[0] (128-bit IPv6 address)" in the diagram to align with RFC 8754 section 2.

Regards,
Rob
2023-06-19
12 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2023-06-19
12 Éric Vyncke
[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-ippm-stamp-srpm-12

Thank you for the work put into this document.

Please find below two blocking DISCUSS …
[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-ippm-stamp-srpm-12

Thank you for the work put into this document.

Please find below two blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and one nit.

Special thanks to Tommy Pauly for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric


# DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

## Section 3

Probably easy to fix :-) `The Session-Reflector SHOULD use the received Destination Node Address as the Source Address in the IP header of the reply test packet`. I am sure that the authors do not want to do spoofing, i.e., add some text about "only if the Destination Node Address is one of the node addresses" or similar.

## Section 4.1.1

Please add text similar to "All other bits are reserved and must be transmitted as 0 and ignored by the receiver".
2023-06-19
12 Éric Vyncke
[Ballot comment]

# COMMENTS

## Section 2.2

Should SRH be also introduced here rather than later ?

## Section 2.3

What are the purpose of …
[Ballot comment]

# COMMENTS

## Section 2.2

Should SRH be also introduced here rather than later ?

## Section 2.3

What are the purpose of the T1, T2, T3, and T4 on the picture ?

Suggest using a reference to the figure.

## Section 3

`Segment Routing Header (SRH) with destination IPv6 address ::1/128` is a little ambiguous... is ::1 in the outer IPv6 header destination address (would be weird), or the inner one ? or even in the segment list of the SRH ?

The 2nd paragraph could benefit:
- mentioning IPv6 flow label along UDP port, addresses, ...
- is "un-intended" a well-defined term in the STAMP framework? It is unclear at this stage what the issue is.

Like Paul Wouters, I wonder why there is a need for a 2nd type while the field length is enough to differentiate between IPv4 and IPv6

## Section 4

Can the Return Path TLV have a length of 0 ?

## Section 4.1.2

Same as above, why there is a need for a 2nd type while the field length is enough to differentiate between IPv4 and IPv6.

### Section 4.1.3.2

This section appears a little light...

1) no word is written about the usual (?) case where there are indeed segments.

2) `may also include the SRv6 Path Segment Identifier of the Return SRv6 Policy` unclear whether it is then the single segment.

# NITS

## BCP 14

Please use the correct BCP 14 template.
2023-06-19
12 Éric Vyncke [Ballot Position Update] New position, Discuss, has been recorded for Éric Vyncke
2023-06-18
12 Paul Wouters
[Ballot comment]
Some TLVs specified in this document have both an address type (IPv4 or IPv6) and a Length field of the IP address. Could …
[Ballot comment]
Some TLVs specified in this document have both an address type (IPv4 or IPv6) and a Length field of the IP address. Could the Length field not be simply omitted and deduced from the type field?
2023-06-18
12 Paul Wouters [Ballot Position Update] New position, No Objection, has been recorded for Paul Wouters
2023-06-17
12 Joseph Touch Assignment of request for Telechat review by INTDIR to Joseph Touch was rejected
2023-06-15
12 Tero Kivinen Request for Telechat review by SECDIR is assigned to Kathleen Moriarty
2023-06-15
12 Bernie Volz Request for Telechat review by INTDIR is assigned to Joseph Touch
2023-06-15
12 Éric Vyncke Requested Telechat review by INTDIR
2023-06-14
12 Martin Duke Placed on agenda for telechat - 2023-06-22
2023-06-14
12 Martin Duke Ballot has been issued
2023-06-14
12 Martin Duke [Ballot Position Update] New position, Yes, has been recorded for Martin Duke
2023-06-14
12 Martin Duke Created "Approve" ballot
2023-06-14
12 Martin Duke IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2023-06-14
12 Martin Duke Ballot writeup was changed
2023-05-29
12 (System) Changed action holders to Martin Duke (IESG state changed)
2023-05-29
12 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2023-05-29
12 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2023-05-29
12 Rakesh Gandhi New version available: draft-ietf-ippm-stamp-srpm-12.txt
2023-05-29
12 Rakesh Gandhi New version accepted (logged-in submitter: Rakesh Gandhi)
2023-05-29
12 Rakesh Gandhi Uploaded new revision
2023-05-27
11 Kathleen Moriarty Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Kathleen Moriarty. Sent review to list.
2023-05-21
11 Gyan Mishra Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Gyan Mishra. Sent review to list. Submission of review completed at an earlier date.
2023-05-21
11 Gyan Mishra Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Gyan Mishra.
2023-05-19
11 (System) Changed action holders to Rakesh Gandhi, Clarence Filsfils, Dan Voyer, Mach Chen, Bart Janssens, Richard Foote, Martin Duke (IESG state changed)
2023-05-19
11 Martin Duke IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead
2023-05-19
11 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2023-05-16
11 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2023-05-16
11 David Dong
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-ippm-stamp-srpm-11. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-ippm-stamp-srpm-11. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the STAMP TLV Types registry on the Simple Two-way Active Measurement Protocol (STAMP) TLV Types registry page located at:

https://www.iana.org/assignments/stamp-tlv-types/

two temporary registrations will be made permanent and their references changed to [ RFC-to-be ] as follows:

Value: 9
Description: Destination Node Address
Reference: [ RFC-to-be ]

Value: 10
Description: Return Path
Reference: [ RFC-to-be ]

Second, a new registry is to be created called the Return Path Sub-TLV Type registry. The registry is to be located on the Simple Two-way Active Measurement Protocol (STAMP) TLV Types registry page located at:

https://www.iana.org/assignments/stamp-tlv-types/

The registration policy for the new registry is as follows:

0 - 175: IETF Review
176 - 239: First Come First Served
240 - 251: Experimental Use
252 - 254: Private Use
255: Reserved

There are five initial registrations in the new registry as follows:

Type Description Reference
-------+-----------------------------------------------+-------------
0 Reserved
1 Return Path Control Code [ RFC-to-be ]
2 Return Address [ RFC-to-be ]
3 SR-MPLS Label Stack of the Return Path [ RFC-to-be ]
4 SRv6 Segment List of the Return Path [ RFC-to-be ]
5 Structured SRv6 Segment List of the Return Path [ RFC-to-be ]
6-254 Unassigned
255 Reserved

Third, a new registry is to be created called the Return Path Control Code Flags registry. The registry is to be located on the Simple Two-way Active Measurement Protocol (STAMP) TLV Types registry page located at:

https://www.iana.org/assignments/stamp-tlv-types/

The registration policy for the new registry is as follows:

Bits 31 - 12: IETF Review
Bits: 11 - 8: First Come First Served
Bits: 7 - 4: Experimental Use
Bits: 3 - 0: Private Use

There is a single initial registration in the new registry as follows:

Bit: 31
Description: Reply Request
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist
2023-05-09
11 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Gyan Mishra
2023-05-08
11 Joel Halpern Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Joel Halpern. Sent review to list.
2023-05-08
11 Rakesh Gandhi New version available: draft-ietf-ippm-stamp-srpm-11.txt
2023-05-08
11 Rakesh Gandhi New version accepted (logged-in submitter: Rakesh Gandhi)
2023-05-08
11 Rakesh Gandhi Uploaded new revision
2023-05-04
10 Tero Kivinen Request for Last Call review by SECDIR is assigned to Kathleen Moriarty
2023-05-04
10 Jean Mahoney Request for Last Call review by GENART is assigned to Joel Halpern
2023-05-03
10 Cindy Morgan IANA Review state changed to IANA - Review Needed
2023-05-03
10 Cindy Morgan
The following Last Call announcement was sent out (ends 2023-05-17):

From: The IESG
To: IETF-Announce
CC: draft-ietf-ippm-stamp-srpm@ietf.org, ippm-chairs@ietf.org, ippm@ietf.org, martin.h.duke@gmail.com, tpauly@apple.com …
The following Last Call announcement was sent out (ends 2023-05-17):

From: The IESG
To: IETF-Announce
CC: draft-ietf-ippm-stamp-srpm@ietf.org, ippm-chairs@ietf.org, ippm@ietf.org, martin.h.duke@gmail.com, tpauly@apple.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Simple TWAMP (STAMP) Extensions for Segment Routing Networks) to Proposed Standard


The IESG has received a request from the IP Performance Measurement WG (ippm)
to consider the following document: - 'Simple TWAMP (STAMP) Extensions for
Segment Routing Networks'
  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
last-call@ietf.org mailing lists by 2023-05-17. 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


  Segment Routing (SR) leverages the source routing paradigm.  SR is
  applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6
  (SRv6) forwarding planes.  This document specifies RFC 8762 (Simple
  Two-Way Active Measurement Protocol (STAMP)) extensions for SR
  networks, for both SR-MPLS and SRv6 forwarding planes by augmenting
  the optional extensions defined in RFC 8972.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-srpm/



No IPR declarations have been submitted directly on this I-D.




2023-05-03
10 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2023-05-03
10 Cindy Morgan Last call announcement was generated
2023-05-02
10 Martin Duke Last call was requested
2023-05-02
10 Martin Duke Last call announcement was generated
2023-05-02
10 Martin Duke Ballot approval text was generated
2023-05-02
10 Martin Duke Ballot writeup was generated
2023-05-02
10 Martin Duke IESG state changed to Last Call Requested from AD Evaluation
2023-05-02
10 Rakesh Gandhi New version available: draft-ietf-ippm-stamp-srpm-10.txt
2023-05-02
10 Rakesh Gandhi New version accepted (logged-in submitter: Rakesh Gandhi)
2023-05-02
10 Rakesh Gandhi Uploaded new revision
2023-05-02
09 (System) Changed action holders to Martin Duke (IESG state changed)
2023-05-02
09 Martin Duke IESG state changed to AD Evaluation from Publication Requested
2023-05-02
09 Tommy Pauly
# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the …
# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document reflects a consensus after long discussions between a few individuals,
along with broader agreement (in less detailed engagement) from a broader segment
of the WG. This got the normal amount of input and consensus for an IPPM document.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Throughout the process on the document, from adoption, there was a lot of discussion
between the authors and one of the area experts in the group (Greg Mirsky), about making
sure that many aspects of the proposal fit into the existing STAMP architecture.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No appeals or discontent have been expressed.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

I am not aware of implementations being formally tracked, but there are several implementations
(at least amongst the authors) who will be using this, and this is being tracked by the SPRING WG.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document is closely related to draft-ietf-spring-stamp-srpm, and both
documents have been discussed and reviewed across the WGs. This document represents
the portions that required the expertise in the IPPM WG.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not applicable.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Not applicable.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Not applicable.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, this document is in good shape as a clear extension to STAMP, and is ready
to be progressed.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

I don't anticipate any particular issues.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

This document is a proposed standard, which is appropriate as an extension to the STAMP
RFCs. The datatracker state does reflect this.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, all authors confirmed they are not aware of IPR on this document.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, all authors responded. The document does have six authors, which is more than usual,
but that is the desire/intent of the authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

No nits found.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

I believe the references are correct as-is.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are RFCs.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97
][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No downward references.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No such references.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No updates to document statuses.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA considerations look good. We've had two early allocations already, and
this document also sets up a new sub-registry ("Return Path Sub-TLV Type"), which
has clear guidance.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

The new sub registry doesn't use Designated Expert.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

2023-05-02
09 Tommy Pauly Responsible AD changed to Martin Duke
2023-05-02
09 Tommy Pauly IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2023-05-02
09 Tommy Pauly IESG state changed to Publication Requested from I-D Exists
2023-05-02
09 Tommy Pauly Document is now in IESG state Publication Requested
2023-05-02
09 Tommy Pauly
# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the …
# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document reflects a consensus after long discussions between a few individuals,
along with broader agreement (in less detailed engagement) from a broader segment
of the WG. This got the normal amount of input and consensus for an IPPM document.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Throughout the process on the document, from adoption, there was a lot of discussion
between the authors and one of the area experts in the group (Greg Mirsky), about making
sure that many aspects of the proposal fit into the existing STAMP architecture.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No appeals or discontent have been expressed.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

I am not aware of implementations being formally tracked, but there are several implementations
(at least amongst the authors) who will be using this, and this is being tracked by the SPRING WG.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document is closely related to draft-ietf-spring-stamp-srpm, and both
documents have been discussed and reviewed across the WGs. This document represents
the portions that required the expertise in the IPPM WG.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not applicable.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Not applicable.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Not applicable.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, this document is in good shape as a clear extension to STAMP, and is ready
to be progressed.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

I don't anticipate any particular issues.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

This document is a proposed standard, which is appropriate as an extension to the STAMP
RFCs. The datatracker state does reflect this.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, all authors confirmed they are not aware of IPR on this document.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, all authors responded. The document does have six authors, which is more than usual,
but that is the desire/intent of the authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

No nits found.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

I believe the references are correct as-is.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are RFCs.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97
][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No downward references.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No such references.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No updates to document statuses.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA considerations look good. We've had two early allocations already, and
this document also sets up a new sub-registry ("Return Path Sub-TLV Type"), which
has clear guidance.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

The new sub registry doesn't use Designated Expert.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

2023-04-18
09 Tommy Pauly Tag Revised I-D Needed - Issue raised by WGLC cleared.
2023-04-18
09 Tommy Pauly IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead
2023-03-28
09 Rakesh Gandhi New version available: draft-ietf-ippm-stamp-srpm-09.txt
2023-03-28
09 Rakesh Gandhi New version accepted (logged-in submitter: Rakesh Gandhi)
2023-03-28
09 Rakesh Gandhi Uploaded new revision
2023-03-27
08 Rakesh Gandhi New version available: draft-ietf-ippm-stamp-srpm-08.txt
2023-03-27
08 Rakesh Gandhi New version accepted (logged-in submitter: Rakesh Gandhi)
2023-03-27
08 Rakesh Gandhi Uploaded new revision
2023-01-31
07 Tommy Pauly Notification list changed to tpauly@apple.com because the document shepherd was set
2023-01-31
07 Tommy Pauly Document shepherd changed to Tommy Pauly
2023-01-31
07 Rakesh Gandhi New version available: draft-ietf-ippm-stamp-srpm-07.txt
2023-01-31
07 Rakesh Gandhi New version accepted (logged-in submitter: Rakesh Gandhi)
2023-01-31
07 Rakesh Gandhi Uploaded new revision
2023-01-20
06 Tommy Pauly Tag Revised I-D Needed - Issue raised by WGLC set.
2023-01-20
06 Tommy Pauly IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2023-01-03
06 Tommy Pauly IETF WG state changed to In WG Last Call from WG Document
2023-01-03
06 Tommy Pauly Changed consensus to Yes from Unknown
2023-01-03
06 Tommy Pauly Intended Status changed to Proposed Standard from None
2022-09-02
06 Rakesh Gandhi New version available: draft-ietf-ippm-stamp-srpm-06.txt
2022-09-02
06 Rakesh Gandhi New version accepted (logged-in submitter: Rakesh Gandhi)
2022-09-02
06 Rakesh Gandhi Uploaded new revision
2022-08-11
05 Rakesh Gandhi New version available: draft-ietf-ippm-stamp-srpm-05.txt
2022-08-11
05 Rakesh Gandhi New version accepted (logged-in submitter: Rakesh Gandhi)
2022-08-11
05 Rakesh Gandhi Uploaded new revision
2022-07-19
04 Marcus Ihlar Added to session: IETF-114: ippm  Fri-1230
2022-07-05
04 Rakesh Gandhi New version available: draft-ietf-ippm-stamp-srpm-04.txt
2022-07-05
04 Rakesh Gandhi New version accepted (logged-in submitter: Rakesh Gandhi)
2022-07-05
04 Rakesh Gandhi Uploaded new revision
2022-02-02
03 Rakesh Gandhi New version available: draft-ietf-ippm-stamp-srpm-03.txt
2022-02-02
03 (System) New version accepted (logged-in submitter: Rakesh Gandhi)
2022-02-02
03 Rakesh Gandhi Uploaded new revision
2021-09-09
02 Rakesh Gandhi New version available: draft-ietf-ippm-stamp-srpm-02.txt
2021-09-09
02 (System) New version accepted (logged-in submitter: Rakesh Gandhi)
2021-09-09
02 Rakesh Gandhi Uploaded new revision
2021-07-25
01 Rakesh Gandhi New version available: draft-ietf-ippm-stamp-srpm-01.txt
2021-07-25
01 (System) New version accepted (logged-in submitter: Rakesh Gandhi)
2021-07-25
01 Rakesh Gandhi Uploaded new revision
2021-06-04
00 Tommy Pauly This document now replaces draft-gandhi-ippm-stamp-srpm instead of None
2021-06-04
00 Rakesh Gandhi New version available: draft-ietf-ippm-stamp-srpm-00.txt
2021-06-04
00 (System) WG -00 approved
2021-06-04
00 Rakesh Gandhi Set submitter to "Rakesh Gandhi ", replaces to draft-gandhi-ippm-stamp-srpm and sent approval email to group chairs: ippm-chairs@ietf.org
2021-06-04
00 Rakesh Gandhi Uploaded new revision