Subject: [tsvwg] Ben Campbell's No Objection on draft-ietf-tsvwg-sctp-failover-15: (with COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Tue, 02 Feb 2016 14:56:23 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-tsvwg-sctp-failover-15: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-failover/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- 3.2: Since PMR is allowed to be greater than zero, there is the
potential to have a non-zero error count but not yet have entered the
potentially failed state. Did I miss guidance on when the error count
might be reset under those conditions? (I found guidance for when in the
potentially failed state.)

-3.2, 4:
The paragraph says the sender MUST follow the following rules, but both
of those rules just say SHOULD. I'm not sure what that means. 

- 3.2, 7: "sender SHOULD clear the error counter"
Why not MUST?

- 4, 3rd paragraph: "handling SHOULD NOT
   be coupled"
Why not MUST?

- 6: The recommended value for PFMR is redundant with an earlier
section.

Editorial:

- There are a number of places where paragraphs are put into long
numbered lists for no apparent reason. Could those not just be normal
paragraphs?  As it is, I keep getting section numbers and paragraph
numbers confused.

- 3.2, 3.ii:"...the sender thus by [RFC4960], section 6.4.1, should
attempt..."

The wording is confusion. I think you mean something to the effect of
"According to [RFC4960] section 6.4.1, when the sender retransmits data
that has timed out, it should attempt..." 

- 3.2, 4, last paragraph:
The current wording can be interpreted ambiguously. I think you mean the
following:
OLD
  The sender MUST NOT change the state and the error counter of
   any destination address regardless of whether it has been chosen
   for transmission or not.
NEW
  The sender MUST NOT change the state and the error counter of
   any destination address simply because it has been chosen for
   transmission.
END

- 6:
RECOMMENDATIONS should not be capitalized.

-7: The section says it's informational. Does that include child
sections? I found at least one 2119 MAY at te end of 7.2.

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 02 Feb 2016 18:40:25 -0600

> that has timed out, it should attempt..."

Well, that was a bit of self-parody :-) 

I meant to say, "The wording is confusing."

Ben.

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 3 Feb 2016 01:31:55 -0800

Hi Ben,

Thank you so much for very detailed comments.
I put my comments in line.

> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-failover/

Yes, If PFMR is bigger than zero, there's a situation where a path has a
non-zero error count, but not haven't entered the PF state.
In this case, the path stays in active state which is the current SCTP
behavior based on RFC4960.
The error counter must not be reset as it prevents entering PF state after
proceeding errors.
In other words, by setting PFMR bigger than zero, you can delay launching
SCTP-PF logic.

> of those rules just say SHOULD. I'm not sure what that means.

Sorry. It means MUST choose one destination. But, it doesn't mean MUST
follow the rules.
We'll clarify this.

> - 3.2, 7: "sender SHOULD clear the error counter"

I think MUST is fine. Please allow me to check with other authors.

> - 4, 3rd paragraph: "handling SHOULD NOT

I think MUST is fine. I will check.

> - 6: The recommended value for PFMR is redundant with an earlier

Yes, It's actually rather intentional. We tried to make it very explicit...
Do you suggest to remove this?

> paragraphs?  As it is, I keep getting section numbers and paragraph

Yes, it's a bit confusing, but we might want to use lists here if possible.
How about using (1) or (A) instead of simple number?

> that has timed out, it should attempt..."

OK. We'll update it.

>    any destination address simply because it has been chosen for

Hmm. I might be wrong. But, the new sentence might not prohibit changing
the state or error count when the destination address has not been chosen
for transmission. Please let me know if I miss something.

> RECOMMENDATIONS should not be capitalized.

We'll fix it.

> sections? I found at least one 2119 MAY at te end of 7.2.
OK. I believe we can change them to may.

Regards,
--
Yoshi

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 03 Feb 2016 10:24:27 -0600

Thanks for the response. Comments inline:

Ben.

> I put my comments in line

[...]

> In other words, by setting PFMR bigger than zero, you can delay 

Does that mean that the error-count cannot be reset prior to entering 
the PF state? What if you get a successful heartbeat or a data 
acknowledgment prior to reaching PFMR?

[...]

> Do you suggest to remove this?

It's up to you. Redundant 2119 keywords can make things error prone for 
future updates. OTOH, they are in the same draft, and they are currently 
consistent, so it's not a huge deal.

> How about using (1) or (A) instead of simple number?

Maybe. It's probably even okay as is, as long as it's on "purpose" :-)

> for transmission. Please let me know if I miss something.

Isn't this section about destination selection? Why would it need to 
talk about cases that don't involve destination selection. As currently 
stated, someone could read it to mean you can never change the state and 
error count at all.

I note that the similar guidance in other sections uses language of the 
form of "as a result of choosing the destination address for data 
transmission."

[...]

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 3 Feb 2016 19:46:35 -0800

Hi Ben,

Thanks for the comments.

On Wed, Feb 3, 2016 at 8:24 AM, Ben Campbell <[email-masked]> wrote:

> Does that mean that the error-count cannot be reset prior to entering the
> PF state? What if you get a successful heartbeat or a data acknowledgment
> prior to reaching PFMR?
>

When the path is in active state, it just follows RFC4960 descriptions. So,
in this case, the error count will be reset as specified in the RFC.
This draft specifies how to enter PF state and how to behave in PF state,
but doesn't specify the behavior in active state.
I think we can put some clarifications of this if that will be helpful.

> Maybe. It's probably even okay as is, as long as it's on "purpose" :-)

OK.

> Isn't this section about destination selection? Why would it need to talk
> about cases that don't involve destination selection. As currently stated,
> someone could read it to mean you can never change the state and error
> count at all.
>

I see your point. I am thinking about using the following sentence to make
it clear on this point.

"The sender MUST NOT change the state and the error counter of any
destination addresses as the result of the selection."

Thanks!
--
Yoshi

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 03 Feb 2016 22:12:13 -0600

On 3 Feb 2016, at 21:46, Yoshifumi Nishida wrote:

>> the

I see, and that makes sense. It might be helpful to add a sentence 
(unless it's already there and I missed it) to mention this is handled 
as per 4960.

[...]

>> talk

That would help, thanks.

Ben.