Re: [secdir] Secdir review of draft-ietf-mmusic-latching-05.txt

["Takeshi Takahashi" <[e-mail]>]

Hi Emil,

I've browsed the new version (-06).
IMHO, this is a nice draft, and I am hoping to see this draft to be
published soon.

> Right. SDP and SIP were indeed transgressing (fixed now) but all of the
> others seem to be expanded on first use. Or am I missing something?

Thank you for checking. I believe you are correct, and the current version
is fine for me.

> Well, they actually refer to quite different things. RTC, as you point
out,
> refers to real-time communication. SBC on the other hand stands for
session
> border controller (which is a signalling entity used by some RTC
services).
> 
> Did I misunderstand the question, or do you believe the text is somehow
> misleading?

Thank you for the clarification.
The texts were very fine, the texts were very easy to follow even for the
people who does not know this area of work (like me) throughout the draft,
and it is me who misinterpreted the texts.
I misinterpreted the very first sentence of the draft in the abstract, and I
believe no change is needed at all.
(From the first sentence, I interpreted as "RTC = SBCs", but I should have
interpreted as "signaling intermediaries in RTC = SBCs").

I personally like this draft very much.
Thank you for writing this document.

Take

> -----Original Message-----
> From: Emil Ivov [mailto:[e-mail]]
> Sent: Friday, May 30, 2014 1:18 AM
> To: Takeshi Takahashi; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: Secdir review of draft-ietf-mmusic-latching-05.txt
> 
> Hey Takeshi,
> 
> Thank you for your review. Comments inline:
> 
> On 22.05.14, 10:57, Takeshi Takahashi wrote:
> > Hello,
> >
> > I have reviewed this document as part of the security directorate's
> > ongoing effort to review all IETF documents being processed by the
> > IESG.  These comments were written primarily for the benefit of the
> > security area directors.  Document editors and WG chairs should treat
> > these comments just like any other last call comments.
> >
> > This document describes the behavior of signaling intermediaries in RTC
> > deployments when performing hosted NAT traversal (HNT).
> > The document begins with summarizing the problems with NAT traversal
> > for protocols such as SIP, and then outlines HNT and the latching
> > mechanism that approach the problems.
> > Nevertheless, this document is not recommending the use of latching.
> > Instead, the document alerts its use and elaborates its security
> > concerns in Section 5 "Security considerations" by showing several
> examples.
> > The security consideration covers issues such as
> > DoS-resistance/resource exhaustion, impersonation and addresses the use
> of encryption mechanism.
> >
> > It is an interesting, tutorial-like document, and I think this
> > document is ready.
> >
> > According to the mmusic mailing list, the security consideration
> > section has been discussed from the early stage of this draft, so the
> > section also seems to be mature, IMHO.
> > A bit of editorial review would be helpful.
> >
> > 1. It could be helpful if you could spell out the abbreviations when
> > they appear at the first time (e.g., UAC, UAS, SIP, SDP, and SBC), not
> > at the second time.
> 
> Right. SDP and SIP were indeed transgressing (fixed now) but all of the
> others seem to be expanded on first use. Or am I missing something?
> 
> > 2. In section 1: " and described in [RFC3424]" should be "as described
> > in [RFC3424]"?
> 
> Fixed.
> 
> > 3. In section 4: "from from" -> "from" ?
> 
> Fixed.
> 
> > The review was based on the document uploaded at
> > https://datatracker.ietf.org/doc/draft-ietf-mmusic-latching/ .
> >
> > By the way, if RTC and SBC are used as the identical terms in this
> > document, why do we use the term RTC (Real Time Communication) in the
> > document tile while we use the term SBC in the main body texts?
> 
> Well, they actually refer to quite different things. RTC, as you point
out,
> refers to real-time communication. SBC on the other hand stands for
session
> border controller (which is a signalling entity used by some RTC
services).
> 
> Did I misunderstand the question, or do you believe the text is somehow
> misleading?
> 
> > In any case, it is a very minor comment, and I think the draft is
> > ready to move forward.
> >
> > Take
> 
> Thanks again, all fixes will be available in the next submission.
> 
> Emil
> 
> --
> https://jitsi.org