Skip to main content

Comparison of Different NAT Traversal Techniques for Media Controlled by the Real-Time Streaming Protocol (RTSP)
RFC 7604

Yes

(Alissa Cooper)

No Objection

(Alia Atlas)
(Barry Leiba)
(Ben Campbell)
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Stephen Farrell)

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

Alvaro Retana No Objection

Comment (2015-05-12 for -15)
I have two comments:

1. The introduction states that multiple levels of NATs (including CGNs) were  not considered.  While I understand the history behind this draft and the time frame when it was written, I would really like to see something mentioned about the potential impact on the different techniques.  (I could only find a brief discussion in section 4.4 (Latching) to the potential effect of multiple NATs/CGN.  Something similar to the text there would be ideal.)

2. Section 8 (Security Considerations) mentions the fact that "three way latching as well as ICE mitigates these security issues and performs the important return-routability check".  Please add a reference to this important check.  I looked at RFC5245 (ICE), but could not find that check described (just connectivity checks); is that what you're referring to with a different name?

(Alissa Cooper; former steering group member) Yes

Yes (for -15)

                            

(Alia Atlas; former steering group member) No Objection

No Objection (for -15)

                            

(Barry Leiba; former steering group member) No Objection

No Objection (for -15)

                            

(Ben Campbell; former steering group member) No Objection

No Objection (for -15)

                            

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

No Objection (2015-05-14 for -15)
Editorial remarks by David Black, posted here for the record as I understand that they are already taken into account in Magnus' temp version.

-- Editorial Comments:

Section 4.6.5

OLD
	The three way latching is significantly securer than
NEW
	Three way latching is significantly more secure than

I saw a number of other editorial items in the newly added text that
I'll leave to the RFC Editor.

idnits 2.13.02 found an obsolete reference:

  -- Obsolete informational reference (is this intentional?): RFC 3489
     (Obsoleted by RFC 5389)

This is intentional, as the draft refers to an obsolete STUN feature
in that obsolete RFC, so this idnits complaint can be ignored.

(Deborah Brungard; former steering group member) No Objection

No Objection (for -15)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (for -15)

                            

(Joel Jaeggli; former steering group member) No Objection

No Objection (for -15)

                            

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2015-05-13 for -15)
I support Alvaro's second comment and think the reference would be helpful to add.

(Stephen Farrell; former steering group member) No Objection

No Objection (for -15)