Skip to main content

Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension
RFC 7496

Yes

(Martin Stiemerling)
(Richard Barnes)
(Spencer Dawkins)

No Objection

(Adrian Farrel)
(Alia Atlas)
(Alissa Cooper)
(Brian Haberman)
(Jari Arkko)
(Joel Jaeggli)
(Pete Resnick)
(Ted Lemon)

Note: This ballot was opened for revision 06 and is now closed.

(Martin Stiemerling; former steering group member) Yes

Yes (for -06)

                            

(Richard Barnes; former steering group member) Yes

Yes (for -06)

                            

(Spencer Dawkins; former steering group member) Yes

Yes (for -06)

                            

(Adrian Farrel; former steering group member) No Objection

No Objection (for -06)

                            

(Alia Atlas; former steering group member) No Objection

No Objection (for -06)

                            

(Alissa Cooper; former steering group member) No Objection

No Objection (for -06)

                            

(Barry Leiba; former steering group member) (was Discuss) No Objection

No Objection (2015-01-26 for -06)
-- Section 3.1 --

   The Limited Retransmissions Policy can be used with data channels in
   the WebRTC protocol stack.  See [I-D.ietf-rtcweb-data-channel] for
   more information.

I wonder whether implementors might misunderstand, and think this is meant to be restrictive.  Please consider changing the wording (here and in 3.2) to something like this:

NEW
   The Limited Retransmissions Policy was designed to be used with
   data channels in the WebRTC protocol stack (see
   [I-D.ietf-rtcweb-data-channel]), and can also be used in other
   appropriate situations.
END

...or maybe...

NEW
   The WebRTC protocol stack (see [I-D.ietf-rtcweb-data-channel]), is
   an example of where the Limited Retransmissions Policy might be
   used.
END

-- Section 3.2 --

   When storing a user message in the send buffer
   while there is not enough available space, the SCTP stack at the
   sender side MAY abandon other user messages of the same SCTP
   association with a priority lower than the provided one.  The
   algorithm for selecting the message being abandoned is implementation
   specific.

A minor point: the first part is written as allowing multiple messages to be abandoned, and the last sentence is written in the singular.  Should the second part say "message(s)" ?

-- Section 4.2 --

The table shows the two policies that come out of RFC 6458 and the two that come from this document.  Is it worth it to create a (FCFS?) registry for these names, to document them and provide references?

(Benoît Claise; former steering group member) No Objection

No Objection (2015-02-03 for -06)
1.
   Using the Priority Policy allows the sender of a user message to
   specify a priority.  When storing a user message in the send buffer
   while there is not enough available space, the SCTP stack at the
   sender side MAY abandon other user messages of the same SCTP
   association with a priority lower than the provided one.

From the same SCTP association or the same stream within the SCTP association? Or is this implementation specific?

2.
While reading through the draft, I was actually wondering how I could use those extensions in IPFIX.
The first one is not applicable. Then I found in section 3.2:

  The Priority Policy can be used in the IPFIX protocol stack.  See
   [RFC7011] for more information.

This is a little lit light. I believe you should explain the use case you have in mind... because I don't believe this was an IPFIX requirement.

(Brian Haberman; former steering group member) No Objection

No Objection (for -06)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (for -06)

                            

(Joel Jaeggli; former steering group member) No Objection

No Objection (for -06)

                            

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2015-02-03 for -06)
Thank you for addressing the SecDir review questions.
https://www.ietf.org/mail-archive/web/secdir/current/msg05262.html

(Pete Resnick; former steering group member) No Objection

No Objection (for -06)

                            

(Stephen Farrell; former steering group member) No Objection

No Objection (2015-02-03 for -06)

So I assume the ability to say "please re-tx this 2^32-1
times" is said to not introduce any new security
consideration, because that is not sent over the wire.
However, could there not be a DoS against a kernel from
userland? And if that limit is set based on some WebRTC JS
(is it? I don't know) then wouldn't that be a way to DoS a
browser and possibly the other end of a WebRTC data channel
too?

So, perhaps noting the above would be good, as well as
saying that implementations SHOULD or MUST have a limit that
they enforce on the max number of re-tx's? (Apologies if
that is there already and I missed it.)

(Ted Lemon; former steering group member) No Objection

No Objection (for -06)