Unaffiliated BFD Echo
draft-ietf-bfd-unaffiliated-echo-10

Prelude:
The mechanism described in draft-ietf-bfd-unaffiliated has significant overlap
with a similar feature specified in BBF TR-146.  A liaison statement was
exchanged with BBF with regard to this work:

https://mailarchive.ietf.org/arch/msg/rtg-bfd/vw31qO1UpD7epoZKXT8_obmY64A/

This internet-draft is largely intended to cover a full IETF specification for
the functionality covered by TR-146 and address the minor issues where TR-146
is incompletely specified.

: 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 has weak but positive Working Group consensus to advance.  This is
somewhat typical of documents progressing through BFD at this point.  That said,
the document has had a degree of strong review from the interested parties.

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

There were several concerns from Greg Mirsky largely regarding the following
points:

1. The mechanism specified in the document bypassed the pre-existing BFD Async
mechanism which permitted the Echo functionality to be enabled.  However, this
is exactly the point of this feature.  Much of the updates to RFC 5880 are
present to permit ths mode.  It's important to note that this mechanism is not
intended to completely replace the Echo mode for RFC 5880 when used in
conjunction with the traditional Async mode.

2. The mechanism specified in the document specified a format for the BFD Echo
packets.  This would appear to contravene RFC 5880, Section 5.  However, the
core behavior in the RFC simply states that the contents of the Echo packets
are a local matter - and this document is simply defining "the local matter".

3. The normative Security Considerations were not strong enough.  Discussion
with the authors and Greg eventually has converged with RFC 5082 GTSM procedures
being required.  This may mean existing implementations of these procedures are
non-conformant.  However, this does not impact interoperability since the entire
point of this feature is a "BFD implementation talking to itself".

4. A further point of discussion is the intended destination and source
addresses used by this mechanism.  RFC 5881, in particular, provides guidance
for the source address selection such that it is not on the same subnet as the
destination address in order to prevent unnecessary ICMP/ND redirect messages.
However, existing implementations (e.g. Broadcom) use exactly behavior with
source and destination addresses being identical.  RFC 5881 makes this behavior
a SHOULD NOT, so using the same considerations for this mechanism avoids making
existing implementations non-conformant.

5. In the discussion over the document's intended status, Greg has noted that the Broadband Forum,
in its liaison For Information TR-146 and draft-ietf-bfd-unaffiliated-echo
(https://datatracker.ietf.org/liaison/1775/) informed the IETF and BFD WG that:

  "In our [Broadband Forum's] opinion, no future standardization
    is required to support TR-146."

Greg also expressed an opinion that the document should be Experimental rather
than Proposed Standard.  As noted in the IETF webpage, "Choosing between
Informational and Experimental Status", it is Shepherd's opinion is that
Experimental is inappropriate.  "The "Experimental" designation typically
denotes a specification that is part of some research or development effort".
In this case, implementations are commercially available utilizing mechanisms
largely similar to those being codified in this Internet-Draft. 

While the procedures in this draft are purely local (the implementation "talks to itself"),
the behavior requires a violation of RFC 5880 with regard to Echo procedures only
being available after the Up state has been achieved in Asynchronous mode. 
It is thus the Chairs' opinion that the text permitting the relaxation of that
requirement is appropriate to standardize for this document, and thus an appropriate
change of status requiring an update to RFC 5880.

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

: 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 recommends) or elsewhere
:    (where)?

There are multiple implementations that claim some deployment of BBF TR-146
implementation behavior.


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

No additional reviews have been requested. 

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

This mechanism currently does not have a YANG module. It may benefit from one
at some point in the future that extends the existing RFC 9314 YANG module for
BFD.

: 7.  If the document contains a YANG module, has the final version of the module
:    been checked with any of the recommended validation tools 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?

N/A

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

N/A

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

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

N/A

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

Proposed Standard.  This mechanism leverages existing BFD procedures in a new
profile (BFD Async over the Echo port) and is appropriate for the standards
track.  The Echo port procedures from the core RFC 5880 intentionally leave
the contents of the Echo packets out of scope from that document, and thus
not a normative change in this document.  However, the ability to use BFD
state machinery without the associated Async session is a normative change
of behavior, even if solely a local one.

: 12. Have reasonable efforts been made to remind all authors of the intellectual
:    property rights (IPR) disclosure obligations described in BCP 79? 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.

IPR attestations:
Weiqiang Cheng:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/ZWMtOxUKZZbECUmmtLU9ZtZeGEk/

Ruixue Wang:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/K9D3KG7MqAm1yk0WaAIOoh5B_Z8/

Xiao Min:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/VQRGASf2GGiv6-J4vp515aY0HYs/

Reshad Rahman:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/9dEQm-IZy_48pjtkKKTu7yWOXYI/

Raj Chetan Boddireddy:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/esD26TKSjvRFJSm0qbcAJ-7EKvo/

It is also necessary to point out that this mechanism is an IETF instantiation
of similar procedures from BBF TR-146.  See liaison statement referenced above.

: 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.  There are exactly five authors.

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

There are no nits noted in version -10.

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

No.

: 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 references, including the Informative BBF TR-146 reference, are publicly
available.

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

No.

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

This document does not change the status of other existing RFCs.

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

This document makes no further requests from IANA.

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

N/A

Prelude:
The mechanism described in draft-ietf-bfd-unaffiliated has significant overlap
with a similar feature specified in BBF TR-146.  A liaison statement was
exchanged with BBF with regard to this work:

https://mailarchive.ietf.org/arch/msg/rtg-bfd/vw31qO1UpD7epoZKXT8_obmY64A/

This internet-draft is largely intended to cover a full IETF specification for
the functionality covered by TR-146 and address the minor issues where TR-146
is incompletely specified.

: 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 has weak but positive Working Group consensus to advance.  This is
somewhat typical of documents progressing through BFD at this point.  That said,
the document has had a degree of strong review from the interested parties.

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

There were several concerns from Greg Mirsky largely regarding the following
points:

1. The mechanism specified in the document bypassed the pre-existing BFD Async
mechanism which permitted the Echo functionality to be enabled.  However, this
is exactly the point of this feature.  Much of the updates to RFC 5880 are
present to permit ths mode.  It's important to note that this mechanism is not
intended to completely replace the Echo mode for RFC 5880 when used in
conjunction with the traditional Async mode.

2. The mechanism specified in the document specified a format for the BFD Echo
packets.  This would appear to contravene RFC 5880, Section 5.  However, the
core behavior in the RFC simply states that the contents of the Echo packets
are a local matter - and this document is simply defining "the local matter".

3. The normative Security Considerations were not strong enough.  Discussion
with the authors and Greg eventually has converged with RFC 5082 GTSM procedures
being required.  This may mean existing implementations of these procedures are
non-conformant.  However, this does not impact interoperability since the entire
point of this feature is a "BFD implementation talking to itself".

4. A further point of discussion is the intended destination and source
addresses used by this mechanism.  RFC 5881, in particular, provides guidance
for the source address selection such that it is not on the same subnet as the
destination address in order to prevent unnecessary ICMP/ND redirect messages.
However, existing implementations (e.g. Broadcom) use exactly behavior with
source and destination addresses being identical.  RFC 5881 makes this behavior
a SHOULD NOT, so using the same considerations for this mechanism avoids making
existing implementations non-conformant.

5. In discussion over the document's intended status, Greg has expressed an opinion
that the document should be Experimental rather than Proposed Standard.  As noted
in the IETF webpage, "Choosing between Informational and Experimental Status", it is
the Shepherd's opinion that Experimental is inappropriate.  "The "Experimental"
designation typically denotes a specification that is part of some research or
development effort".  In this case, implementations are commercially available
utilizing mechanisms largely similar to those being codified in this Internet-Draft. 

While the procedures in this draft are purely local (the implementation "talks to itself"),
the behavior requires a violation of RFC 5880 with regard to Echo procedures only
being available after the Up state has been achieved in Asynchronous mode. 
It is thus the Chairs' opinion that the text permitting the relaxation of that
requirement is appropriate to standardize for this document, and thus an appropriate
change of status requiring an update to RFC 5880.

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

: 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 recommends) or elsewhere
:    (where)?

There are multiple implementations that claim some deployment of BBF TR-146
implementation behavior.


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

No additional reviews have been requested. 

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

This mechanism currently does not have a YANG module. It may benefit from one
at some point in the future that extends the existing RFC 9314 YANG module for
BFD.

: 7.  If the document contains a YANG module, has the final version of the module
:    been checked with any of the recommended validation tools 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?

N/A

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

N/A

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

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

N/A

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

Proposed Standard.  This mechanism leverages existing BFD procedures in a new
profile (BFD Async over the Echo port) and is appropriate for the standards
track.  The Echo port procedures from the core RFC 5880 intentionally leave
the contents of the Echo packets out of scope from that document, and thus
not a normative change in this document.  However, the ability to use BFD
state machinery without the associated Async session is a normative change
of behavior, even if solely a local one.

: 12. Have reasonable efforts been made to remind all authors of the intellectual
:    property rights (IPR) disclosure obligations described in BCP 79? 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.

IPR attestations:
Weiqiang Cheng:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/ZWMtOxUKZZbECUmmtLU9ZtZeGEk/

Ruixue Wang:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/K9D3KG7MqAm1yk0WaAIOoh5B_Z8/

Xiao Min:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/VQRGASf2GGiv6-J4vp515aY0HYs/

Reshad Rahman:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/9dEQm-IZy_48pjtkKKTu7yWOXYI/

Raj Chetan Boddireddy:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/esD26TKSjvRFJSm0qbcAJ-7EKvo/

It is also necessary to point out that this mechanism is an IETF instantiation
of similar procedures from BBF TR-146.  See liaison statement referenced above.

: 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.  There are exactly five authors.

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

There are no nits noted in version -10.

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

No.

: 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 references, including the Informative BBF TR-146 reference, are publicly
available.

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

No.

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

This document does not change the status of other existing RFCs.

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

This document makes no further requests from IANA.

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

N/A

Prelude:
The mechanism described in draft-ietf-bfd-unaffiliated has significant overlap
with a similar feature specified in BBF TR-146.  A liaison statement was
exchanged with BBF with regard to this work:

https://mailarchive.ietf.org/arch/msg/rtg-bfd/vw31qO1UpD7epoZKXT8_obmY64A/

This internet-draft is largely intended to cover a full IETF specification for
the functionality covered by TR-146 and address the minor issues where TR-146
is incompletely specified.

: 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 has weak but positive Working Group consensus to advance.  This is
somewhat typical of documents progressing through BFD at this point.  That said,
the document has had a degree of strong review from the interested parties.

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

There were several concerns from Greg Mirsky largely regarding the following
points:

1. The mechanism specified in the document bypassed the pre-existing BFD Async
mechanism which permitted the Echo functionality to be enabled.  However, this
is exactly the point of this feature.  Much of the updates to RFC 5880 are
present to permit ths mode.  It's important to note that this mechanism is not
intended to completely replace the Echo mode for RFC 5880 when used in
conjunction with the traditional Async mode.

2. The mechanism specified in the document specified a format for the BFD Echo
packets.  This would appear to contravene RFC 5880, Section 5.  However, the
core behavior in the RFC simply states that the contents of the Echo packets
are a local matter - and this document is simply defining "the local matter".

3. The normative Security Considerations were not strong enough.  Discussion
with the authors and Greg eventually has converged with RFC 5082 GTSM procedures
being required.  This may mean existing implementations of these procedures are
non-conformant.  However, this does not impact interoperability since the entire
point of this feature is a "BFD implementation talking to itself".

4. A further point of discussion is the intended destination and source
addresses used by this mechanism.  RFC 5881, in particular, provides guidance
for the source address selection such that it is not on the same subnet as the
destination address in order to prevent unnecessary ICMP/ND redirect messages.
However, existing implementations (e.g. Broadcom) use exactly behavior with
source and destination addresses being identical.  RFC 5881 makes this behavior
a SHOULD NOT, so using the same considerations for this mechanism avoids making
existing implementations non-conformant.

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

: 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 recommends) or elsewhere
:    (where)?

There are multiple implementations that claim some deployment of BBF TR-146
implementation behavior.


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

No additional reviews have been requested. 

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

This mechanism currently does not have a YANG module. It may benefit from one
at some point in the future that extends the existing RFC 9314 YANG module for
BFD.

: 7.  If the document contains a YANG module, has the final version of the module
:    been checked with any of the recommended validation tools 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?

N/A

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

N/A

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

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

N/A

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

Proposed Standard.  This mechanism leverages existing BFD procedures in a new
profile (BFD Async over the Echo port) and is appropriate for the standards
track.  The Echo port procedures from the core RFC 5880 intentionally leave
the contents of the Echo packets out of scope from that document, and thus
not a normative change in this document.  However, the ability to use BFD
state machinery without the associated Async session is a normative change
of behavior, even if solely a local one.

: 12. Have reasonable efforts been made to remind all authors of the intellectual
:    property rights (IPR) disclosure obligations described in BCP 79? 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.

IPR attestations:
Weiqiang Cheng:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/ZWMtOxUKZZbECUmmtLU9ZtZeGEk/

Ruixue Wang:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/K9D3KG7MqAm1yk0WaAIOoh5B_Z8/

Xiao Min:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/VQRGASf2GGiv6-J4vp515aY0HYs/

Reshad Rahman:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/9dEQm-IZy_48pjtkKKTu7yWOXYI/

Raj Chetan Boddireddy:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/esD26TKSjvRFJSm0qbcAJ-7EKvo/

It is also necessary to point out that this mechanism is an IETF instantiation
of similar procedures from BBF TR-146.  See liaison statement referenced above.

: 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.  There are exactly five authors.

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

There are no nits noted in version -10.

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

No.

: 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 references, including the Informative BBF TR-146 reference, are publicly
available.

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

No.

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

This document does not change the status of other existing RFCs.

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

This document makes no further requests from IANA.

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

N/A

Prelude:
The mechanism described in draft-ietf-bfd-unaffiliated has significant overlap
with a similar feature specified in BBF TR-146.  A liaison statement was
exchanged with BBF with regard to this work:

https://mailarchive.ietf.org/arch/msg/rtg-bfd/vw31qO1UpD7epoZKXT8_obmY64A/

This internet-draft is largely intended to cover a full IETF specification for
the functionality covered by TR-146 and address the minor issues where TR-146
is incompletely specified.

: 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 has weak but positive Working Group consensus to advance.  This is
somewhat typical of documents progressing through BFD at this point.  That said,
the document has had a degree of strong review from the interested parties.

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

There were several concerns from Greg Mirsky largely regarding the following
points:

1. The mechanism specified in the document bypassed the pre-existing BFD Async
mechanism which permitted the Echo functionality to be enabled.  However, this
is exactly the point of this feature.  Much of the updates to RFC 5880 are
present to permit ths mode.  It's important to note that this mechanism is not
intended to completely replace the Echo mode for RFC 5880 when used in
conjunction with the traditional Async mode.

2. The mechanism specified in the document specified a format for the BFD Echo
packets.  This would appear to contravene RFC 5880, Section 5.  However, the
core behavior in the RFC simply states that the contents of the Echo packets
are a local matter - and this document is simply defining "the local matter".

3. The normative Security Considerations were not strong enough.  Discussion
with the authors and Greg eventually has converged with RFC 5082 GTSM procedures
being required.  This may mean existing implementations of these procedures are
non-conformant.  However, this does not impact interoperability since the entire
point of this feature is a "BFD implementation talking to itself".

4. A further point of discussion is the intended destination and source
addresses used by this mechanism.  RFC 5881, in particular, provides guidance
for the source address selection such that it is not on the same subnet as the
destination address in order to prevent unnecessary ICMP/ND redirect messages.
However, existing implementations (e.g. Broadcom) use exactly behavior with
source and destination addresses being identical.  RFC 5881 makes this behavior
a SHOULD NOT, so using the same considerations for this mechanism avoids making
existing implementations non-conformant.

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

: 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 recommends) or elsewhere
:    (where)?

There are multiple implementations that claim some deployment of BBF TR-146
implementation behavior.


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

No additional reviews have been requested. 

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

This mechanism currently does not have a YANG module. It may benefit from one
at some point in the future that extends the existing RFC 9314 YANG module for
BFD.

: 7.  If the document contains a YANG module, has the final version of the module
:    been checked with any of the recommended validation tools 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?

N/A

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

N/A

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

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

N/A

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

Proposed Standard.  This mechanism leverages existing BFD procedures in a new
profile (BFD Async over the Echo port) and is appropriate for the standards
track.  The Echo port procedures from the core RFC 5880 intentionally leave
the contents of the Echo packets out of scope from that document, and thus
not a normative change in this document.  However, the ability to use BFD
state machinery without the associated Async session is a normative change
of behavior, even if solely a local one.

: 12. Have reasonable efforts been made to remind all authors of the intellectual
:    property rights (IPR) disclosure obligations described in BCP 79? 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.

IPR attestations:
Weiqiang Cheng:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/ZWMtOxUKZZbECUmmtLU9ZtZeGEk/

Ruixue Wang:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/K9D3KG7MqAm1yk0WaAIOoh5B_Z8/

Xiao Min:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/VQRGASf2GGiv6-J4vp515aY0HYs/

Reshad Rahman:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/9dEQm-IZy_48pjtkKKTu7yWOXYI/

Raj Chetan Boddireddy:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/esD26TKSjvRFJSm0qbcAJ-7EKvo/

It is also necessary to point out that this mechanism is an IETF instantiation
of similar procedures from BBF TR-146.  See liaison statement referenced above.

: 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.  There are exactly five authors.

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

There are no nits noted in version -10.

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

No.

: 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 references, including the Informative BBF TR-146 reference, are publicly
available.

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

No.

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

This document does not change the status of other existing RFCs.

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

This document makes no further requests from IANA.

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

N/A

Prelude:
The mechanism described in draft-ietf-bfd-unaffiliated has significant overlap
with a similar feature specified in BBF TR-146.  A liaison statement was
exchanged with BBF with regard to this work:

https://mailarchive.ietf.org/arch/msg/rtg-bfd/vw31qO1UpD7epoZKXT8_obmY64A/

This internet-draft is largely intended to cover a full IETF specification for
the functionality covered by TR-146 and address the minor issues where TR-146
is incompletely specified.

: 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 has weak but positive Working Group consensus to advance.  This is
somewhat typical of documents progressing through BFD at this point.

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

There were several concerns from Greg Mirsky largely regarding the following
points:

1. The mechanism specified in the document bypassed the pre-existing BFD Async
mechanism which permitted the Echo functionality to be enabled.  However, this
is exactly the point of this feature.  Much of the updates to RFC 5880 are
present to permit ths mode.  It's important to note that this mechanism is not
intended to completely replace the Echo mode for RFC 5880 when used in
conjunction with the traditional Async mode.

2. The mechanism specified in the document specified a format for the BFD Echo
packets.  This would appear to contravene RFC 5880, Section 5.  However, the
core behavior in the RFC simply states that the contents of the Echo packets
are a local matter - and this document is simply defining "the local matter".

3. The normative Security Considerations are not strong enough, particularly in
the requirement that RFC 5082 GTSM procedures MUST be utilized by the host
providing the loopback services.  While a great idea in general, this document
largely exists to provide an IETF definition of a feature already described in
BBF TR-146.  Such default limitation of the loopback may not be widely deployed
and thus the more restrictive MUST requirements for GTSM would make existing
deployments non-conformant.

4. A further point of discussion is the intended destination and source
addresses used by this mechanism.  RFC 5881, in particular, provides guidance
for the source address selection such that it is not on the same subnet as the
destination address in order to prevent unnecessary ICMP/ND redirect messages.
However, existing implementations (e.g. Broadcom) use exactly behavior with
source and destination addresses being identical.  RFC 5881 makes this behavior
a SHOULD NOT, so using the same considerations for this mechanism avoids making
existing implementations non-conformant.

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

: 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 recommends) or elsewhere
:    (where)?

There are multiple implementations that claim some deployment of BBF TR-146
implementation behavior.


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

No additional reviews have been requested. 

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

This mechanism currently does not have a YANG module. It may benefit from one
at some point in the future that extends the existing RFC 9314 YANG module for
BFD.

: 7.  If the document contains a YANG module, has the final version of the module
:    been checked with any of the recommended validation tools 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?

N/A

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

N/A

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

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

N/A

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

Proposed Standard.  This mechanism leverages existing BFD procedures in a new
profile (BFD Async over the Echo port) and is appropriate for the standards
track.  The Echo port procedures from the core RFC 5880 intentionally leave
the contents of the Echo packets out of scope from that document, and thus
not a normative change in this document.  However, the ability to use BFD
state machinery without the associated Async session is a normative change
of behavior, even if solely a local one.

: 12. Have reasonable efforts been made to remind all authors of the intellectual
:    property rights (IPR) disclosure obligations described in BCP 79? 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.

IPR attestations from the authors are currently pending.  (10 April, 2023)  The
document will be progressed to the IESG once the attestations are all accounted
for.

IPR attestations:
Weiqiang Cheng:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/ZWMtOxUKZZbECUmmtLU9ZtZeGEk/

Ruixue Wang:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/K9D3KG7MqAm1yk0WaAIOoh5B_Z8/

Xiao Min:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/VQRGASf2GGiv6-J4vp515aY0HYs/

Reshad Rahman:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/9dEQm-IZy_48pjtkKKTu7yWOXYI/

Raj Chetan Boddireddy:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/esD26TKSjvRFJSm0qbcAJ-7EKvo/

It is also necessary to point out that this mechanism is an IETF instantiation
of similar procedures from BBF TR-146.  See liaison statement referenced above.

: 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.  There are exactly five authors.

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

There are no nits noted in version -07.

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

No.

: 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 references, including the Informative BBF TR-146 reference, are publicly
available.

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

No.

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

This document does not change the status of other existing RFCs.

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

This document makes no further requests from IANA.

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

N/A

Prelude:
The mechanism described in draft-ietf-bfd-unaffiliated has significant overlap
with a similar feature specified in BBF TR-146.  A liaison statement was
exchanged with BBF with regard to this work:

https://mailarchive.ietf.org/arch/msg/rtg-bfd/vw31qO1UpD7epoZKXT8_obmY64A/

This internet-draft is largely intended to cover a full IETF specification for
the functionality covered by TR-146 and address the minor issues where TR-146
is incompletely specified.

: 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 has weak but positive Working Group consensus to advance.  This is
somewhat typical of documents progressing through BFD at this point.

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

There were several concerns from Greg Mirsky largely regarding the following
points:

1. The mechanism specified in the document bypassed the pre-existing BFD Async
mechanism which permitted the Echo functionality to be enabled.  However, this
is exactly the point of this feature.  Much of the updates to RFC 5880 are
present to permit ths mode.  It's important to note that this mechanism is not
intended to completely replace the Echo mode for RFC 5880 when used in
conjunction with the traditional Async mode.

2. The mechanism specified in the document specified a format for the BFD Echo
packets.  This would appear to contravene RFC 5880, Section 5.  However, the
core behavior in the RFC simply states that the contents of the Echo packets
are a local matter - and this document is simply defining "the local matter".

3. The normative Security Considerations are not strong enough, particularly in
the requirement that RFC 5082 GTSM procedures MUST be utilized by the host
providing the loopback services.  While a great idea in general, this document
largely exists to provide an IETF definition of a feature already described in
BBF TR-146.  Such default limitation of the loopback may not be widely deployed
and thus the more restrictive MUST requirements for GTSM would make existing
deployments non-conformant.

4. A further point of discussion is the intended destination and source
addresses used by this mechanism.  RFC 5881, in particular, provides guidance
for the source address selection such that it is not on the same subnet as the
destination address in order to prevent unnecessary ICMP/ND redirect messages.
However, existing implementations (e.g. Broadcom) use exactly behavior with
source and destination addresses being identical.  RFC 5881 makes this behavior
a SHOULD NOT, so using the same considerations for this mechanism avoids making
existing implementations non-conformant.

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

: 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 recommends) or elsewhere
:    (where)?

There are multiple implementations that claim some deployment of BBF TR-146
implementation behavior.


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

No additional reviews have been requested. 

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

This mechanism currently does not have a YANG module. It may benefit from one
at some point in the future that extends the existing RFC 9314 YANG module for
BFD.

: 7.  If the document contains a YANG module, has the final version of the module
:    been checked with any of the recommended validation tools 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?

N/A

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

N/A

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

The document is integrating comments raised during Working Group Last Call and
should be ready for progression afterwards.

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

N/A

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

Proposed Standard.  This mechanism leverages existing BFD procedures in a new
profile (BFD Async over the Echo port) and is appropriate for the standards
track.

: 12. Have reasonable efforts been made to remind all authors of the intellectual
:    property rights (IPR) disclosure obligations described in BCP 79? 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.

IPR attestations from the authors are currently pending.  (10 April, 2023)  The
document will be progressed to the IESG once the attestations are all accounted
for.

IPR attestations:
Weiqiang Cheng:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/ZWMtOxUKZZbECUmmtLU9ZtZeGEk/

Ruixue Wang:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/K9D3KG7MqAm1yk0WaAIOoh5B_Z8/

Xiao Min:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/VQRGASf2GGiv6-J4vp515aY0HYs/

Reshad Rahman:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/9dEQm-IZy_48pjtkKKTu7yWOXYI/

Raj Chetan Boddireddy:

It is also necessary to point out that this mechanism is an IETF instantiation
of similar procedures from BBF TR-146.  See liaison statement referenced above.

: 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.  There are exactly five authors.

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

There are no nits noted in version -06.

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

No.

: 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 references, including the Informative BBF TR-146 reference, are publicly
available.

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

No.

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

This document does not change the status of other existing RFCs.

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

This document makes no further requests from IANA.

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

N/A

Prelude:
The mechanism described in draft-ietf-bfd-unaffiliated has significant overlap
with a similar feature specified in BBF TR-146.  A liaison statement was
exchanged with BBF with regard to this work:

https://mailarchive.ietf.org/arch/msg/rtg-bfd/vw31qO1UpD7epoZKXT8_obmY64A/

This internet-draft is largely intended to cover a full IETF specification for
the functionality covered by TR-146 and address the minor issues where TR-146
is incompletely specified.

: 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 has weak but positive Working Group consensus to advance.  This is
somewhat typical of documents progressing through BFD at this point.

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

There were several concerns from Greg Mirsky largely regarding the following
points:

1. The mechanism specified in the document bypassed the pre-existing BFD Async
mechanism which permitted the Echo functionality to be enabled.  However, this
is exactly the point of this feature.  Much of the updates to RFC 5880 are
present to permit ths mode.  It's important to note that this mechanism is not
intended to completely replace the Echo mode for RFC 5880 when used in
conjunction with the traditional Async mode.

2. The mechanism specified in the document specified a format for the BFD Echo
packets.  This would appear to contravene RFC 5880, Section 5.  However, the
core behavior in the RFC simply states that the contents of the Echo packets
are a local matter - and this document is simply defining "the local matter".

3. The normative Security Considerations are not strong enough, particularly in
the requirement that RFC 5082 GTSM procedures MUST be utilized by the host
providing the loopback services.  While a great idea in general, this document
largely exists to provide an IETF definition of a feature already described in
BBF TR-146.  Such default limitation of the loopback may not be widely deployed
and thus the more restrictive MUST requirements for GTSM would make existing
deployments non-conformant.

4. A further point of discussion is the intended destination and source
addresses used by this mechanism.  RFC 5881, in particular, provides guidance
for the source address selection such that it is not on the same subnet as the
destination address in order to prevent unnecessary ICMP/ND redirect messages.
However, existing implementations (e.g. Broadcom) use exactly behavior with
source and destination addresses being identical.  RFC 5881 makes this behavior
a SHOULD NOT, so using the same considerations for this mechanism avoids making
existing implementations non-conformant.

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

: 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 recommends) or elsewhere
:    (where)?

There are multiple implementations that claim some deployment of BBF TR-146
implementation behavior.


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

No additional reviews have been requested. 

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

This mechanism currently does not have a YANG module. It may benefit from one
at some point in the future that extends the existing RFC 9314 YANG module for
BFD.

: 7.  If the document contains a YANG module, has the final version of the module
:    been checked with any of the recommended validation tools 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?

N/A

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

N/A

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

The document is integrating comments raised during Working Group Last Call and
should be ready for progression afterwards.

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

N/A

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

Proposed Standard.  This mechanism leverages existing BFD procedures in a new
profile (BFD Async over the Echo port) and is appropriate for the standards
track.

: 12. Have reasonable efforts been made to remind all authors of the intellectual
:    property rights (IPR) disclosure obligations described in BCP 79? 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.

IPR attestations from the authors are currently pending.  (10 April, 2023)  The
document will be progressed to the IESG once the attestations are all accounted
for.

It is also necessary to point out that this mechanism is an IETF instantiation
of similar procedures from BBF TR-146.  See liaison statement referenced above.

: 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.  There are exactly five authors.

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

There are no nits noted in version -06.

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

No.

: 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 references, including the Informative BBF TR-146 reference, are publicly
available.

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

No.

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

This document does not change the status of other existing RFCs.

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

This document makes no further requests from IANA.

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

N/A