Add the interconnection-component-has-local-protocol constraint

[DimitriZhurkin]

Committer Notes

This constraint tests the following scenario:
An interconnection component has at least one local IPv4 Address, IPv6 Address, URI, or FQDN.

IMPORTANT: This constraint is blocked until OSCAL adds the following props:

1. fqdn
2. uri

Related issues:

1. #930
2. #2092

All Submissions:

• Have you selected the correct base branch per Contributing guidance?
• Have you set "Allow edits and access to secrets by maintainers"?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• Have you squashed any non-relevant commits and commit messages? [instructions]
• Have you added an explanation of what your changes do and why you'd like us to include them?
• If applicable, have all FedRAMP Documents Related to OSCAL Adoption affected by the changes in this issue have been updated.?
• If applicable, does this PR reference the issue it addresses and explain how it addresses the issue?

By submitting a pull request, you are agreeing to provide this contribution under the CC0 1.0 Universal public domain dedication.

[aj-stein-gsa]

As an intermediate possibility to do the following?

1. Update the PR and rebase to current develop
2. Point it to the canary branch
3. Review, and if approved, merge into the canary branch

[Gabeblis]

You should create a new branch off of canary and cherry-pick the commits for this issue so that we aren't bringing extra unrelated changes into the PR.

[Gabeblis]

After looking at Brian's comment on issue #930, it looks like we're not looking for FDQN. I suggest you make these edits to align with his comments.

[aj-stein-gsa]

@DimitriZhurkin, can you please address feedback and/or resolve the issues. I do not see any feedback since Gabe's review so I am not sure what the current state is here.

[brian-ruf]

After looking at Brian's comment on issue #930, it looks like we're not looking for FDQN. I suggest you make these edits to align with his comments.

@Gabeblis while your read of my comment is correct, the comment itself is erroneously missing fqdn. That is my oversight.

ipv4_address, ipv6_address, uri, and fqdn should be considered a set. Anyplace the address of a service or node needs to be specified, the method of specification can be any combination of those four choices.

I think I realized fqdn should be part of that list after I wrote that comment and failed to circle back and correct it.

[DimitriZhurkin]

After looking at Brian's comment on issue #930, it looks like we're not looking for FDQN. I suggest you make these edits to align with his comments.

FQDN is valid (#1089 (comment)).

[DimitriZhurkin]

@DimitriZhurkin, can you please address feedback and/or resolve the issues. I do not see any feedback since Gabe's review so I am not sure what the current state is here.

I think all changes have been implemented now.