Re: [pim] Murray Kucherawy's No Objection on draft-ietf-pim-bfd-p2mp-use-case-09: (with COMMENT)

[Greg Mirsky <[e-mail]>]

Hi Murray,
thank you for your review and the question about the use of the normative
language in Section 2.1. That "SHOULD" refers to the following procedures
defined in RFC 8562:
   To shut down a multipoint session in a controlled fashion, the head
   MUST administratively set bfd.SessionState in the MultipointHead
   session to either Down or AdminDown and SHOULD set
   bfd.RequiredMinRxInterval to zero.  The session SHOULD send BFD
   Control packets in this state for a period equal to
   (bfd.DesiredMinTxInterval * bfd.DetectMult).  Alternatively, the head
   MAY stop transmitting BFD Control packets and not send any more BFD
   Control packets with the new state (Down or AdminDown).  Tails will
   declare the multipoint session down only after the Detection Time
   interval runs out.
The alternative to what is required in RFC 8562 is also listed in that
paragraph - "stop transmitting BFD control packets". I think that it will
be right to s/SHOULD/MUST/ in Section 2.1 of the draft. What is your
opinion?

Regards,
Greg

On Wed, Dec 1, 2021 at 9:40 PM Murray Kucherawy via Datatracker <
[e-mail]> wrote:

> Murray Kucherawy has entered the following ballot position for
> draft-ietf-pim-bfd-p2mp-use-case-09: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-pim-bfd-p2mp-use-case/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> The shepherd writeup says simply "Proposed standard" in answer to the
> question
> "Why is this the proper type of RFC?".
>
> The SHOULDs in Section 2.1 give the implementer a choice.  I suggest
> including
> some guidance about how to make that choice, or perhaps more concretely,
> when
> one might opt not to do what the SHOULD says.
>
>
>
>