Path Monitoring System/Head-end based MPLS Ping and Traceroute in Inter-domain Segment Routing Networks
draft-ietf-mpls-spring-inter-domain-oam-12

Document Shepherd: Adrian Farrel (adrian@olddog.co.uk)

NOTE WELL: This document refers to "multi-domain SR-MPLS". There may be
confusion caused by the description of a "domain" (or "SR domain") in RFC 8402.
This document is not referring to that type of domain. It refers to IGP-domains
(OSPF areas or IS-IS levels) and Autonomous Systems. We have worked to make
that clear in the text, but be careful what baggage you bring to your review!

## 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?

There was no dissent, however, it proved hard to get supporting comments from
the working group. The initial 3 week last call ran over Christmas, and was
extended for another 2 weeks because of the low response. Eventually, several
key contributors to the working group performed reviews and made supportive
comments. These led to discussions with the authors and a couple of rounds of
updates.

Thus, "strong concurrence of a few individuals, with others being silent"

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

No controversy.

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, no discontent.

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)?

There is an RFC 7942 Implementation Status section as Section 12 of this
document. It describes a single vendor's prototype implementation.

## 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 work is very much related to the work of the SPRING working group. The
working group last call was shared on the SPRING list and resulted in supportive
comments from one participant. There was no objection raised.

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.

No formal expert reviews required.
A Routing Directorate review was performed in preparation for working group last
call (https://datatracker.ietf.org/doc/review-ietf-mpls-spring-inter-domain-oam-05-rtgdir-early-richardson-2023-06-28/)
This found a lot of small issues that were fixed prior to last call.

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]?

No YANG.

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.

No formal language

## 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?

My review of -10 led to a fair number of minor comments and nits. The authors
resolved most of these with -11. A further round of discussions led to -12 and
closure of all open comments.

I now consider the document to be clear enough and complete.

The need for the document is something of a stretch in today's immediate
deployments since multi-IGP-domain, or multi-AS SR-MPLS is likely dependent on
wider experience with single-domain. But, unlike MPLS-TE which saw very limited
multi-domain deployment, it is possible that the future holds more hope for
multi-domain SR-MPLS.

The design is acceptable (not necessarily how I would have done it, but that is
not important as there is agreement on the approach the authors have documented)

The document is ready for consideration by the AD.

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?

Careful reviewing against the RTG Dir "common issues" by the RTG Dir reviewer
and the Shepherd. Should all be good.

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?

Proposed Standard correctly noted.
The document describes new protocol elements.

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.

All five authors and the two contributors made IPR declarations at the time of working group last call

Shraddha Hegde https://mailarchive.ietf.org/arch/msg/mpls/uQ40wG5xjMdqTBZwPjeQynz3F_I/
Kapil Arora https://mailarchive.ietf.org/arch/msg/mpls/oHG3cHeWRA7So8dd1MS6-W1lNCY/
Mukul Srivastava https://mailarchive.ietf.org/arch/msg/mpls/hNfxPtkXkTUGaevMMYQVBzt1IuE/
Samson Ninan https://mailarchive.ietf.org/arch/msg/mpls/hYFrH1xPJXk602XYUTo9SnYv7_E/
Nagendra Kumar Nainar https://mailarchive.ietf.org/arch/msg/mpls/JQk5eMrFJe7x3kJcsU3X7cdZnlw/
Carlos Pignataro https://mailarchive.ietf.org/arch/msg/mpls/IEW9yOlOWUu2HsF29yCGyYQwxxU/
Zafar Ali https://mailarchive.ietf.org/arch/msg/mpls/kGZgGI-QN2eC1tQskO_6cb4A07Y/

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.

By responding to the IPR poll (see #12) all authors and contributors were made aware
of their association with the document. None objected.

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.)

idnits is clean on -12 except for warnings about things that look like references
but aren't.

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

I'm OK with the split (but see #17).

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

Nope. All are IETF output.

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.

There is a normative downref to Informational RFC 9087.
It is not listed in the downref registry.
I would prefer this to remain a Normative reference, but it could be made
Informative without significant harm.

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?

Nope, everything is an RFC.

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 changes suggested or needed.

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]).

I took over this document as shepherd late in the cycle. Thus, my review of -10
came after all updates after WGLC.

My review uncovered a fair number of minor comments and nits, but nothing of
significant substance. It also pointed to idnits that needed to be fixed.

The authors posted -11 and -12 resolving my issues to my satisfaction.

The IANA section is clear and identifies the registries correctly. The new
registry that is requested has all the necessary information.

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 registry uses "Standards Action"

Document Shepherd: Adrian Farrel (adrian@olddog.co.uk)

NOTE WELL: This document refers to "multi-domain SR-MPLS". There may be
confusion caused by the description of a "domain" (or "SR domain") in RFC 8402.
This document is not referring to that type of domain. It refers to IGP-domains
(OSPF areas or IS-IS levels) and Autonomous Systems. We have worked to make
that clear in the text, but be careful what baggage you bring to your review!

## 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?

There was no dissent, however, it proved hard to get supporting comments from
the working group. The initial 3 week last call ran over Christmas, and was
extended for another 2 weeks because of the low response. Eventually, several
key contributors to the working group performed reviews and made supportive
comments. These led to discussions with the authors and a couple of rounds of
updates.

Thus, "strong concurrence of a few individuals, with others being silent"

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

No controversy.

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, no discontent.

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)?

There is an RFC 7942 Implementation Status section as Section 12 of this
document. It describes a single vendor's prototype implementation.

## 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 work is very much related to the work of the SPRING working group. The
working group last call was shared on the SPRING list and resulted in supportive
comments from one participant. There was no objection raised.

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.

No formal expert reviews required.
A Routing Directorate review was performed in preparation for working group last
call (https://datatracker.ietf.org/doc/review-ietf-mpls-spring-inter-domain-oam-05-rtgdir-early-richardson-2023-06-28/)
This found a lot of small issues that were fixed prior to last call.

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]?

No YANG.

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.

No formal language

## 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?

My review of -10 led to a fair number of minor comments and nits. The authors
resolved most of these with -11. A further round of discussions led to -12 and
closure of all open comments.

I now consider the document to be clear enough and complete.

The need for the document is something of a stretch in today's immediate
deployments since multi-IGP-domain, or multi-AS SR-MPLS is likely dependent on
wider experience with single-domain. But, unlike MPLS-TE which saw very limited
multi-domain deployment, it is possible that the future holds more hope for
multi-domain SR-MPLS.

The design is acceptable (not necessarily how I would have done it, but that is
not important as there is agreement on the approach the authors have documented)

The document is ready for consideration by the AD.

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?

Careful reviewing against the RTG Dir "common issues" by the RTG Dir reviewer
and the Shepherd. Should all be good.

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?

Proposed Standard correctly noted.
The document describes new protocol elements.

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.

All five authors and the two contributors made IPR declarations at the time of working group last call

Shraddha Hegde https://mailarchive.ietf.org/arch/msg/mpls/uQ40wG5xjMdqTBZwPjeQynz3F_I/
Kapil Arora https://mailarchive.ietf.org/arch/msg/mpls/oHG3cHeWRA7So8dd1MS6-W1lNCY/
Mukul Srivastava https://mailarchive.ietf.org/arch/msg/mpls/hNfxPtkXkTUGaevMMYQVBzt1IuE/
Samson Ninan https://mailarchive.ietf.org/arch/msg/mpls/hYFrH1xPJXk602XYUTo9SnYv7_E/
Nagendra Kumar Nainar https://mailarchive.ietf.org/arch/msg/mpls/JQk5eMrFJe7x3kJcsU3X7cdZnlw/
Carlos Pignataro https://mailarchive.ietf.org/arch/msg/mpls/IEW9yOlOWUu2HsF29yCGyYQwxxU/
Zafar Ali https://mailarchive.ietf.org/arch/msg/mpls/kGZgGI-QN2eC1tQskO_6cb4A07Y/

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.

By responding to the IPR poll (see #12) all authors and contributors were made aware
of their association with the document. None objected.

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.)

idnits is clean on -12 except for warnings about things that look like references
but aren't.

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

I'm OK with the split (but see #17).

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

Nope. All are IETF output.

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.

There is a normative downref to Informational RFC 9087.
It is not listed in the downref registry.
I would prefer this to remain a Normative reference, but it could be made
Informative without significant harm.

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?

Nope, everything is an RFC.

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 changes suggested or needed.

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]).

I took over this document as shepherd late in the cycle. Thus, my review of -10
came after all updates after WGLC.

My review uncovered a fair number of minor comments and nits, but nothing of
significant substance. It also pointed to idnits that needed to be fixed.

The authors posted -11 and -12 resolving my issues to my satisfaction.

The IANA section is clear and identifies the registries correctly. The new
registry that is requested has all the necessary information.

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 registry uses "Standards Action"

DRAFT  DRAFT  DRAFT  DRAFT  DRAFT


Document Shepherd: Adrian Farrel (adrian@olddog.co.uk)

NOTE WELL: This document refers to "multi-domain SR-MPLS". There may be
confusion caused by the description of a "domain" (or "SR domain") in RFC 8402.
This document is not referring to that type of domain. It refers to IGP-domains
(OSPF areas or IS-IS levels) and Autonomous Systems. We have worked to make
that clear in the text, but be careful what baggage you bring to your review!

## 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?

There was no dissent, however, it proved hard to get supporting comments from
the working group. The initial 3 week last call ran over Christmas, and was
extended for another 2 weeks because of the low response. Eventually, several
key contributors to the working group performed reviews and made supportive
comments. These led to discussions with the authors and a couple of rounds of
updates.

Thus, "strong concurrence of a few individuals, with others being silent"

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

No controversy.

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, no discontent.

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)?

There is an RFC 7942 Implementation Status section as Section 12 of this
document. It describes a single vendor's prototype implementation.

## 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 work is very much related to the work of the SPRING working group. The
working group last call was shared on the SPRING list and resulted in supportive
comments from one participant. There was no objection raised.

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.

No formal expert reviews required.
A Routing Directorate review was performed in preparation for working group last
call (https://datatracker.ietf.org/doc/review-ietf-mpls-spring-inter-domain-oam-05-rtgdir-early-richardson-2023-06-28/)
This found a lot of small issues that were fixed prior to last call.

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]?

No YANG.

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.

No formal language

## 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?

My review of -10 led to a fair number of minor comments and nits. The authors
resolved these with -11.

I now consider the document to be clear enough and complete.

The need for the document is something of a stretch in today's immediate
deployments since multi-IGP-domain, or multi-AS SR-MPLS is likely dependent on
wider experience with single-domain. But, unlike MPLS-TE which saw very limited
multi-domain deployment, it is possible that the future holds more hope for
multi-domain SR-MPLS.

The design is acceptable (not necessarily how I would have done it, but that is
not important as their is agreement on the approach the authors have documented)

The document is ready for consideration by the AD.

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?

Careful reviewing against the RTG Dir "common issues" by the RTG Dir reviewer
and the Shepherd. Should all be good.

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?

Proposed Standard correctly noted.
The document describes new protocol elements.

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.

All five authors and the two contributors made IPR declarations at the time of working group last call

Shraddha Hegde https://mailarchive.ietf.org/arch/msg/mpls/uQ40wG5xjMdqTBZwPjeQynz3F_I/
Kapil Arora https://mailarchive.ietf.org/arch/msg/mpls/oHG3cHeWRA7So8dd1MS6-W1lNCY/
Mukul Srivastava https://mailarchive.ietf.org/arch/msg/mpls/hNfxPtkXkTUGaevMMYQVBzt1IuE/
Samson Ninan https://mailarchive.ietf.org/arch/msg/mpls/hYFrH1xPJXk602XYUTo9SnYv7_E/
Nagendra Kumar Nainar https://mailarchive.ietf.org/arch/msg/mpls/JQk5eMrFJe7x3kJcsU3X7cdZnlw/
Carlos Pignataro https://mailarchive.ietf.org/arch/msg/mpls/IEW9yOlOWUu2HsF29yCGyYQwxxU/
Zafar Ali https://mailarchive.ietf.org/arch/msg/mpls/kGZgGI-QN2eC1tQskO_6cb4A07Y/

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.

By responding to the IPR poll (see #12) all authors and contributors were made aware
of their association with the document. None objected.

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.)

idnits is clean on -11 except for warnings about things that look like references
but aren't.

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

I'm OK with the split (but see #17).

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

Nope. All are IETF output.

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.

There is a normative downref to Informational RFC 9087.
It is not listed in the downref registry.
I would prefer this to remain a Normative reference, but it could be made
Informative without harm.

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?

Nope, everything is an RFC.

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 changes suggested or needed.

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]).

I took over this document as shepherd late in the cycle. Thus, my review of -10
came after all updates after WGLC.

My review uncovered a fair number of minor comments and nits, but nothing of
significant substance. It also pointed to idnits that needed to be fixed.

The authors posted -11 resolving my issues to my satisfaction.

The IANA section is clear and identifies the registries correctly. The new
registry that is requested has all the necessary information.

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 registry uses "Standards Action"