Thanks to Chris M. Lonvick for the secdir review.

# Internet AD comments for draft-ietf-pim-light-10
CC @ekline

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

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

## Nits

### S3.4

* "out going interface (OIF)" ->
  "outgoing interface (OIF)"

DOWNREF [RFC6559] from this Proposed Standard to Experimental RFC6559. (For
IESG discussion. It seems this DOWNREF was not mentioned in the Last Call and
also seems to not appear in the DOWNREF registry.)

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

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

Section 3.2.2, paragraph 1
> wn stream BIER edge router, it can be send over the BIER tunnel to the upstre
>                                    ^^^^^^^
There may an error in the verb form "be send".

Section 3.2.3, paragraph 2
>  more BIER edge routers in a BIER sub-domain [draft-ietf-bier-pim-signaling].
>                                   ^^^^^^^^^^
This word is normally spelled as one.

Section 3.2.3, paragraph 2
> nding multicast streams until the out going interface (OIF) expires. Other p
>                                   ^^^^^^^^^
The word "outgoing" is spelled as one word.

Section 3.4, paragraph 3
> d for determining which peer is doing a active transport open to the neighbor
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.5, paragraph 2
> ensures only Join/Prune messages arriving on a configured PLI are processed.
>                                  ^^^^^^^^^^^
The usual preposition after "arriving" is "at", not "on". Did you mean
"arriving at"?

There are a lot of naked SHOULDs in this document.  SHOULD presents implementers with a choice, and it's a good idea to give them some guidance around how to make it.  For instance, very early on, we have this:

"... if a router receives a Join/Prune message from a particular IP source address and it has not seen a PIM Hello message from that source address, then the Join/Prune message SHOULD be discarded without further processing."

Why's that only a SHOULD?  Are there circumstances in which I might continue with processing?  What does it to do the protocol or operation if I do?

Most or all of the SHOULDs in this document had me asking a question like this one.  I suggest reviewing them and considering whether each one should (a) really be MUST, (b) really be MAY, or (c) stay SHOULD but with some guidance added.

Thank you to Mallory Knodel for the GENART review.

Thanks for working on this specification. The TCP and SCTP usage looks good to me. Thanks Micheal Tuxen for the TSVART review.

Thanks, Hooman, for quickly addressing my previous DISCUSS ballot (and the associated COMMENTs).

See: https://mailarchive.ietf.org/arch/msg/pim/az5rGUZvVOW9_WNXA4jiPEWy2vI/