From nobody Fri May 27 15:17:46 2016 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAEA12D0B8; Fri, 27 May 2016 15:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQFyeBrNbXJ3; Fri, 27 May 2016 15:17:42 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB73B12D099; Fri, 27 May 2016 15:17:42 -0700 (PDT) Received: from [10.0.1.24] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u4RMHbRe011608 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 27 May 2016 17:17:37 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.24] From: "Ben Campbell" To: draft-ietf-straw-b2bua-rtcp.all@ietf.org, straw@ietf.org Date: Fri, 27 May 2016 17:17:35 -0500 Message-ID: <1E42F55A-8365-45B5-A08F-25D513514AB1@nostrum.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_0DBBC14C-43E4-4763-A746-8AA04942250F_=" Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: Christer Holmberg Subject: [straw] Review of draft-ietf-straw-b2bua-rtcp-10 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 22:17:45 -0000 --=_MailMate_0DBBC14C-43E4-4763-A746-8AA04942250F_= Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit [Oops, I sent that from the wrong address. Please send any discussion to ben@nostrum.com] Hi, Here is my review of draft-ietf-straw-b2bua-rtcp-10. I mentioned in my AD evaluation of a previous version that the draft needed editing for clarity and readability. In my opinion, this version is improved, but still a bit rough in places. I have a few substantive comments and quite a few editorial comments. This is not a formal AD evaluation. That will occur after the chairs submit a new publication request. But I think we need to work through this before it will be ready for IETF last call. Thanks, Ben. ------------ ### Substantive Comments: * The intended status is proposed standard. Do people really expect b2bua vendors to implement the rules in this draft? Do they expect existing b2bua implementations to be updated? * Abstract - Is it really true that media passthrough b2buas need to implement the full RTP stack? * Section 1: * 2nd paragraph - The following has been overtaken by events: >"These topologies are currently being updated to address new commonly >encountered scenarios as well [RFC7667]." * paragraph after figure 1, last sentence - Why does it matter that the RTP packet is audio? * Section 3, last paragraph - This paragraph seems to argue that the fact that existing b2buas do not follow specs is a reason to create more specs. That seems questionable. * Section 3.1: * Second Paragraph * 2nd sentence: Do you mean if the endpoints sent bad SDP, or if the b2bua messes up the SDP? * "but having them synced during setup would help nonetheless" - Help how? Please elaborate, or consider dropping the text in the parentheses. * Section 3.2 * third paragraph from end: "...it SHOULD update the related ’ssrc’ attributes...": Why not MUST? Can you envision reasonable circumstances in which one might do follow this? * last paragraph, 2nd to last sentence - Wouldn’t the primary reason to do this be because the endpoint on the non-supporting side didn’t support reduced-size? Wouldn’t the b2bua need to advertise the feature to discover that? * Section 4 * Last paragraph, 2nd to last sentence - If you think people will really pay attention, then this might be a good place for a MUST or SHOULD * Section 6 * The first paragraph describes this draft as a "summary" and "best common practice overview" That seems to argue against the proposed standard status (see previous comment). ### Editorial Comments and Nits: * IDNits reports unused references for RFCs 4568, 5764 and 4588 * Please consider proofreading for unnecessary filler words, such as "besides", "basically", "just", "also", "as well", "instead,", "as such", etc. To some degree, this is a matter of style, but when used heavily they can impact readability. * Section 1, First Paragraph: * s/completelely/completely * I'm not sure what "... can lead to unexpected situations the IETF is trying to address" means. * does "most deployed" mean "most commonly deployed"? * 2nd paragraph - The following is convoluted and hard to parse. Can you simplify it? >"...manipulate the session description [RFC4566], in order to >have all RTP and RTCP [RFC3550] pass through it as well within >the context of an SDP offer/answer [RFC3264]." * Third paragraph - I'm not sure what this means: >"... their effectiveness may be affected as a consequence" * Paragraph after Figure 1: >"As part of this process, though, it is also rewriting some of the >RTP header information on the way, for instance because that’s how >its RTP relaying stack works:" * That basically says it rewrites RTP headers because it does. That’s not a reason. I suggest either offering a real reason, or don’t try to offer a reason at all. * The antecedent for "it" is ambiguous * 2nd paragraph from end of paragraph * Sentence starting with "Since the B2BUA" is very hard to parse. * Sentence starting with "As a consequence" is also hard to parse. * Last paragraph in section, last sentence * Should "such feedback" be "RTCP"? * Are there things they _are_ supposed to break? * Section 3: * First paragraph: * s/anticipated/described ; (or mentioned). * 2 of the 3 categories have numbers, but the 3rd does not. * Section 3.1 * 2nd paragraph: * s/"in case"/"when" (or "if"). (This pattern occurs repeatedly) * s/"is generating"/"generates" * What does "taking into account the original session description" mean? Maybe s/"taking into account"/"using" * Third paragraph: * Are there uninterested participants? * "It SHOULD NOT, though, blindly forward all SDP attributes," - Isn’t the idea that it should forward any attributes that it doesn’t have a specific reason not to forward? (i.e. default to forwarding?) * Fourth paragraph, first sentence: Hard to parse. Does this mean the same as: “Aside from RTCP, the relay may need to hide information due to local policy.”? * Section 3.2: * First paragraph - Would it make sense to s/"is able to inspect"/"inspects" and s/"be able to modify"/"modify"? * Third paragraph: Consider s/"is receiving"/"receives". * Fourth paragraph: I can't parse the sentence. * Feedback messages - It’s a little confusing having the following FCI entries at the same section outline level as the feedback message entry. Consider making “Feedback messages” a separate section. * ECN Section - The section is hard to parse. * Third paragraph from end: * consider s/"is going to change"/"changes" * 2nd to last sentence: Does this mean “prevent a UAC from _sending_ NACK messages that would never reach the intended recipients”? * last sentence - There’s something wrong with this sentence. Do you mean all three instances of "RTCP message" to really be be "RTCP message"? * Second to last paragraph: * First sentence is hard to parse * "not use it on the other side, if it’s not supported." - If what doesn't support it? The b2bua? The endpoint? * "any of the parties in the communication does not support" - s/does/do * s/involve/use * "no conflicting RTP payload type numbers on both sides" - should this say "either side"? * "ensure no conflict" - I suggest "prevent conflict" or "ensure that there is no conflict" * What do you mean by "domain" in this context? * Section 3.3, last paragraph, last sentence - Sentence hard to parse. * Section 4 - Seems like this belongs in security considerations * Third paragraph - s/Terminarion/Termination --=_MailMate_0DBBC14C-43E4-4763-A746-8AA04942250F_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

[Oops, I sent that from the wrong address. Please send an= y discussion to ben@nostrum.com]

Hi,

Here is my review of draft-ietf-straw-b2bua-rtcp-10. I me= ntioned in my AD evaluation of a previous version that the draft needed e= diting for clarity and readability. In my opinion, this version is improv= ed, but still a bit rough in places. I have a few substantive comments an= d quite a few editorial comments.

This is not a formal AD evaluation. That will occur after= the chairs submit a new publication request. But I think we need to work= through this before it will be ready for IETF last call.

Thanks,

Ben.

Substantive Comments:

  • The intended status is proposed standard. Do people r= eally expect b2bua vendors to implement the rules in this draft? Do they = expect existing b2bua implementations to be updated?

  • Abstract - Is it really true that media passthrough b= 2buas need
    to implement the full RTP stack?

  • Section 1:

    • 2nd paragraph - The following has been overtaken by e= vents:

      "These topologies are currently being updated to address = new commonly
      encountered scenarios as well [RFC7667]."

    • paragraph after figure 1, last sentence - Why does it= matter that the RTP packet is audio?

  • Section 3, last paragraph - This paragraph seems to a= rgue that the fact that
    existing b2buas do not follow specs is a reason to create more specs. Tha= t seems
    questionable.

  • Section 3.1:

    • Second Paragraph
      • 2nd sentence: Do you mean if the endpoints sent bad SDP, or if the b2bua messes up the SDP?
      • "but having them synced during setup would help nonetheless" - Help how? Please elaborate, or consider dropping the text in the parentheses.

  • Section 3.2

    • third paragraph from end: "...it SHOULD update the related =E2=80=99s= src=E2=80=99 attributes...": Why not MUST? Can you envision reasonable circumstances i= n which one might do follow this?
    • last paragraph, 2nd to last sentence - Wouldn=E2=80=99t the primary r= eason to do this be because the endpoint on the non-supporting side didn=E2=80=99t support= reduced-size? Wouldn=E2=80=99t the b2bua need to advertise the feature to discover that?

  • Section 4

    • Last paragraph, 2nd to last sentence - If you think people will reall= y pay attention, then this might be a good place for a MUST or SHOULD

  • Section 6

    • The first paragraph describes this draft as a "summary" and "best com= mon practice overview" That seems to argue against the proposed standard status (see previous co= mment).

Editorial Comments and Nits:

  • IDNits reports unused references for RFCs 4568, 5764 = and 4588

  • Please consider proofreading for unnecessary filler w= ords, such as
    "besides", "basically", "just", "also", "as well", "instead,", "as such",= etc.
    To some degree, this is a matter of style, but when used heavily
    they can impact readability.

  • Section 1, First Paragraph:

    • s/completelely/completely
    • I'm not sure what "... can lead to unexpected situations the IETF is trying to address" means.
    • does "most deployed" mean "most commonly deployed"?

    • 2nd paragraph - The following is convoluted and hard = to parse.
      Can you simplify it?

      "...manipulate the session description [RFC4566], in orde= r to
      have all RTP and RTCP [RFC3550] pass through it as well within
      the context of an SDP offer/answer [RFC3264]."

    • Third paragraph - I'm not sure what this means:

      "... their effectiveness may be affected as a consequence= "

    • Paragraph after Figure 1:

      "As part of this process, though, it is also rewriting so= me of the
      RTP header information on the way, for instance because that=E2=80=99s ho= w
      its RTP relaying stack works:"

      • That basically says it rewrites RTP headers because it does. That=E2=80=99s not a reason. I suggest either offering a real reason, or don=E2=80=99t try to offer a reason at all.
      • The antecedent for "it" is ambiguous

    • 2nd paragraph from end of paragraph

      • Sentence starting with "Since the B2BUA" is very hard to parse.
      • Sentence starting with "As a consequence" is also hard to parse.
        • =

    • Last paragraph in section, last sentence

      • Should "such feedback" be "RTCP"?
      • Are there things they are supposed to break?

  • Section 3:

    • First paragraph:
      • s/anticipated/described ; (or mentioned).
      • 2 of the 3 categories have numbers, but the 3rd does not.

  • Section 3.1

    • 2nd paragraph:
      • s/"in case"/"when" (or "if"). (This pattern occurs repeatedly)
      • s/"is generating"/"generates"
      • What does "taking into account the original session description" mean? Maybe s/"taking into account"/"using"
    • Third paragraph:
      • Are there uninterested participants?
      • "It SHOULD NOT, though, blindly forward all SDP attributes," - Isn=E2= =80=99t the idea that it should forward any attributes that it doesn=E2=80=99t have a specific reason not to forward? (i.e. default to forwarding?)
        • =
    • Fourth paragraph, first sentence: Hard to parse. Does this mean the same as: =E2=80=9CAside from RTCP, the relay may need to hide information= due to local policy.=E2=80=9D?

  • Section 3.2:

    • First paragraph - Would it make sense to s/"is able to inspect"/"insp= ects" and s/"be able to modify"/"modify"?
    • Third paragraph: Consider s/"is receiving"/"receives".
    • Fourth paragraph: I can't parse the sentence.
    • Feedback messages - It=E2=80=99s a little confusing having the follow= ing FCI entries at the same section outline level as the feedback message entry. Consider making =E2=80=9CFeedback messages=E2=80=9D a separate section.
    • ECN Section - The section is hard to parse.
    • Third paragraph from end:
      • consider s/"is going to change"/"changes"
      • 2nd to last sentence: Does this mean =E2=80=9Cprevent a UAC from = sending NACK messages that would never reach the intended recipients=E2=80=9D?
      • last sentence - There=E2=80=99s something wrong with this sentence. D= o you mean all three instances of "RTCP message" to really be be "RTCP message"?
    • Second to last paragraph:
      • First sentence is hard to parse
      • "not use it on the other side, if it=E2=80=99s not supported." - If w= hat doesn't support it? The b2bua? The endpoint?
      • "any of the parties in the communication does not support" - s/does/d= o
      • s/involve/use
      • "no conflicting RTP payload type numbers on both sides" - should this= say "either side"?
      • "ensure no conflict" - I suggest "prevent conflict" or "ensure that t= here is no conflict"
      • What do you mean by "domain" in this context?

  • Section 3.3, last paragraph, last sentence - Sentence= hard to parse.

  • Section 4 - Seems like this belongs in security consi= derations

    • Third paragraph - s/Terminarion/Termination
--=_MailMate_0DBBC14C-43E4-4763-A746-8AA04942250F_=-- From nobody Sat May 28 01:17:16 2016 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B46F312D5D0 for ; Sat, 28 May 2016 01:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlTDBUzu9aes for ; Sat, 28 May 2016 01:17:12 -0700 (PDT) Received: from smtpcmd05149.aruba.it (smtpcmd0871.aruba.it [62.149.156.71]) by ietfa.amsl.com (Postfix) with ESMTP id 6F94212B05F for ; Sat, 28 May 2016 01:17:11 -0700 (PDT) Received: from rainpc ([87.21.4.164]) by smtpcmd08.ad.aruba.it with bizsmtp id zkH81s00h3YKVjr01kH8F9; Sat, 28 May 2016 10:17:10 +0200 Date: Sat, 28 May 2016 10:17:07 +0200 From: Lorenzo Miniero To: "Ben Campbell" Message-ID: <20160528101707.2ae27b3d@rainpc> In-Reply-To: <1E42F55A-8365-45B5-A08F-25D513514AB1@nostrum.com> References: <1E42F55A-8365-45B5-A08F-25D513514AB1@nostrum.com> Organization: Meetecho X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: draft-ietf-straw-b2bua-rtcp.all@ietf.org, straw@ietf.org, Christer Holmberg Subject: Re: [straw] Review of draft-ietf-straw-b2bua-rtcp-10 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2016 08:17:15 -0000 On Fri, 27 May 2016 17:17:35 -0500 "Ben Campbell" wrote: > [Oops, I sent that from the wrong address. Please send any discussion to= =20 > ben@nostrum.com] >=20 > Hi, >=20 > Here is my review of draft-ietf-straw-b2bua-rtcp-10. I mentioned in my=20 > AD evaluation of a previous version that the draft needed editing for=20 > clarity and readability. In my opinion, this version is improved, but=20 > still a bit rough in places. I have a few substantive comments and quite= =20 > a few editorial comments. >=20 > This is not a formal AD evaluation. That will occur after the chairs=20 > submit a new publication request. But I think we need to work through=20 > this before it will be ready for IETF last call. >=20 Hello Ben, thanks for this detailed review! I'll address this soon and come back with = an updated version in the next few days. Just a quick comment on the intended status. I believe it was defined a Pro= posed Standard as the idea was to discipline the behaviour of B2BUAs, as ot= her documents in this WG do on other aspects (e.g., DTLS-SRTP). Considering= the document is called "Guidelines", I personally wouldn't object to turn = it into a BCP, although I think keeping it a Proposed Standard would streng= hten the importance of doing it right. That said, would a BCP document stil= l need the MUSTs in some places where we have SHOULDs? Thanks, Lorenzo > Thanks, >=20 > Ben. >=20 > ------------ >=20 >=20 > ### Substantive Comments: >=20 > * The intended status is proposed standard. Do people really expect=20 > b2bua vendors to implement the rules in this draft? Do they expect=20 > existing b2bua implementations to be updated? >=20 > * Abstract - Is it really true that media passthrough b2buas need > to implement the full RTP stack? >=20 > * Section 1: >=20 > * 2nd paragraph - The following has been overtaken by events: >=20 > >"These topologies are currently being updated to address new =20 > commonly > >encountered scenarios as well [RFC7667]." =20 >=20 > * paragraph after figure 1, last sentence - Why does it matter that= =20 > the RTP packet is audio? >=20 > * Section 3, last paragraph - This paragraph seems to argue that the=20 > fact that > existing b2buas do not follow specs is a reason to create more specs.= =20 > That seems > questionable. >=20 > * Section 3.1: >=20 > * Second Paragraph > * 2nd sentence: Do you mean if the endpoints sent > bad SDP, or if the b2bua messes up the SDP? > * "but having them synced during setup would > help nonetheless" - Help how? Please elaborate, or consider > dropping the text in the parentheses. >=20 > * Section 3.2 >=20 > * third paragraph from end: "...it SHOULD update the related=20 > =E2=80=99ssrc=E2=80=99 > attributes...": Why not MUST? Can you envision reasonable=20 > circumstances in which > one might do follow this? >=20 >=20 > * last paragraph, 2nd to last sentence - Wouldn=E2=80=99t the primary= =20 > reason to do this > be because the endpoint on the non-supporting side didn=E2=80=99t sup= port=20 > reduced-size? Wouldn=E2=80=99t > the b2bua need to advertise the feature to discover that? >=20 > * Section 4 > * Last paragraph, 2nd to last sentence - If you think people will=20 > really pay attention, > then this might be a good place for a MUST or SHOULD >=20 > * Section 6 > * The first paragraph describes this draft as a "summary" and "best= =20 > common practice overview" > That seems to argue against the proposed standard status (see=20 > previous comment). >=20 >=20 > ### Editorial Comments and Nits: >=20 > * IDNits reports unused references for RFCs 4568, 5764 and 4588 >=20 > * Please consider proofreading for unnecessary filler words, such as > "besides", "basically", "just", "also", "as well", "instead,", "as=20 > such", etc. > To some degree, this is a matter of style, but when used heavily > they can impact readability. >=20 > * Section 1, First Paragraph: >=20 > * s/completelely/completely > * I'm not sure what "... can lead to unexpected situations the > IETF is trying to address" means. > * does "most deployed" mean "most commonly deployed"? > * 2nd paragraph - The following is convoluted and hard to parse. > Can you simplify it? >=20 > >"...manipulate the session description [RFC4566], in order to > >have all RTP and RTCP [RFC3550] pass through it as well within > >the context of an SDP offer/answer [RFC3264]." =20 >=20 > * Third paragraph - I'm not sure what this means: >=20 > >"... their effectiveness may be affected as a consequence" =20 >=20 > * Paragraph after Figure 1: >=20 > >"As part of this process, though, it is also rewriting some of =20 > the > >RTP header information on the way, for instance because that=E2=80= =99s =20 > how > >its RTP relaying stack works:" =20 >=20 > * That basically says it rewrites RTP headers because it does. > That=E2=80=99s not a reason. I suggest either offering a real= =20 > reason, > or don=E2=80=99t try to offer a reason at all. > * The antecedent for "it" is ambiguous >=20 > * 2nd paragraph from end of paragraph > * Sentence starting with "Since the B2BUA" is very hard to=20 > parse. > * Sentence starting with "As a consequence" is also hard to=20 > parse. >=20 > * Last paragraph in section, last sentence > * Should "such feedback" be "RTCP"? > * Are there things they _are_ supposed to break? >=20 > * Section 3: >=20 > * First paragraph: > * s/anticipated/described ; (or mentioned). > * 2 of the 3 categories have numbers, but the 3rd does not. >=20 > * Section 3.1 >=20 > * 2nd paragraph: > * s/"in case"/"when" (or "if"). (This pattern occurs=20 > repeatedly) > * s/"is generating"/"generates" > * What does "taking into account the original session=20 > description" > mean? Maybe s/"taking into account"/"using" >=20 > * Third paragraph: > * Are there uninterested participants? > * "It SHOULD NOT, though, blindly forward all SDP attributes,"=20 > - Isn=E2=80=99t > the idea that it should forward any attributes that it=20 > doesn=E2=80=99t > have a specific reason not to forward? (i.e. default to=20 > forwarding?) >=20 > * Fourth paragraph, first sentence: Hard to parse. Does this mean=20 > the > same as: =E2=80=9CAside from RTCP, the relay may need to hide=20 > information due > to local policy.=E2=80=9D? >=20 > * Section 3.2: >=20 > * First paragraph - Would it make sense to s/"is able to=20 > inspect"/"inspects" and > s/"be able to modify"/"modify"? >=20 > * Third paragraph: Consider s/"is receiving"/"receives". >=20 > * Fourth paragraph: I can't parse the sentence. >=20 > * Feedback messages - It=E2=80=99s a little confusing having the=20 > following FCI > entries at the same section outline level as the feedback=20 > message entry. > Consider making =E2=80=9CFeedback messages=E2=80=9D a separate se= ction. >=20 > * ECN Section - The section is hard to parse. >=20 > * Third paragraph from end: > * consider s/"is going to change"/"changes" > * 2nd to last sentence: Does this mean =E2=80=9Cprevent a UAC f= rom=20 > _sending_ > NACK messages that would never reach the intended=20 > recipients=E2=80=9D? > * last sentence - There=E2=80=99s something wrong with this=20 > sentence. Do you mean > all three instances of "RTCP message" to really be be "RTCP= =20 > message"? >=20 > * Second to last paragraph: > * First sentence is hard to parse > * "not use it on the other side, if it=E2=80=99s not supported.= " -=20 > If what doesn't support it? > The b2bua? The endpoint? > * "any of the parties in the communication does not support" -= =20 > s/does/do > * s/involve/use > * "no conflicting RTP payload type numbers on both sides" -=20 > should this say "either side"? > * "ensure no conflict" - I suggest "prevent conflict" or=20 > "ensure that there is no conflict" > * What do you mean by "domain" in this context? >=20 > * Section 3.3, last paragraph, last sentence - Sentence hard to parse. >=20 > * Section 4 - Seems like this belongs in security considerations >=20 > * Third paragraph - s/Terminarion/Termination >=20 From nobody Tue May 31 04:12:15 2016 Return-Path: X-Original-To: straw@ietf.org Delivered-To: straw@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7738212D1B0; Tue, 31 May 2016 04:12:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160531111211.15329.67941.idtracker@ietfa.amsl.com> Date: Tue, 31 May 2016 04:12:11 -0700 Archived-At: Cc: straw@ietf.org Subject: [straw] I-D Action: draft-ietf-straw-b2bua-rtcp-11.txt X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 11:12:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Sip Traversal Required for Applications to Work of the IETF. Title : Guidelines to support RTCP end-to-end in Back-to-Back User Agents (B2BUAs) Authors : Lorenzo Miniero Sergio Garcia Murillo Victor Pascual Filename : draft-ietf-straw-b2bua-rtcp-11.txt Pages : 17 Date : 2016-05-31 Abstract: SIP Back-to-Back User Agents (B2BUAs) are often envisaged to also be on the media path, rather than just intercepting signalling. This means that B2BUAs often implement an RTP/RTCP stack as well, thus leading to separate multimedia sessions that the B2BUA correlates and bridges together. If not disciplined, though, this behaviour can severely impact the communication experience, especially when statistics and feedback information contained in RTCP messages get lost because of mismatches in the reported data. This document defines the proper behaviour B2BUAs should follow when also acting on the signalling/media plane in order to preserve the end-to-end functionality of RTCP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-straw-b2bua-rtcp-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-straw-b2bua-rtcp-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 31 04:12:36 2016 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B90C12D558 for ; Tue, 31 May 2016 04:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipsjQAVwUjAU for ; Tue, 31 May 2016 04:12:33 -0700 (PDT) Received: from smtpweb120.aruba.it (smtpweb120.aruba.it [62.149.158.120]) by ietfa.amsl.com (Postfix) with ESMTP id CE03712D591 for ; Tue, 31 May 2016 04:12:26 -0700 (PDT) Received: from lminiero ([93.44.66.215]) by smtpcmd03.ad.aruba.it with bizsmtp id 0zCP1t01F4efdGD01zCQ8Y; Tue, 31 May 2016 13:12:25 +0200 Date: Tue, 31 May 2016 13:12:23 +0200 From: Lorenzo Miniero To: "Ben Campbell" Message-ID: <20160531131223.176ff3ef@lminiero> In-Reply-To: <1E42F55A-8365-45B5-A08F-25D513514AB1@nostrum.com> References: <1E42F55A-8365-45B5-A08F-25D513514AB1@nostrum.com> Organization: Meetecho X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: draft-ietf-straw-b2bua-rtcp.all@ietf.org, straw@ietf.org, Christer Holmberg Subject: Re: [straw] Review of draft-ietf-straw-b2bua-rtcp-10 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 11:12:36 -0000 On Fri, 27 May 2016 17:17:35 -0500 "Ben Campbell" wrote: > [Oops, I sent that from the wrong address. Please send any discussion > to ben@nostrum.com] >=20 > Hi, >=20 > Here is my review of draft-ietf-straw-b2bua-rtcp-10. I mentioned in > my AD evaluation of a previous version that the draft needed editing > for clarity and readability. In my opinion, this version is improved, > but still a bit rough in places. I have a few substantive comments > and quite a few editorial comments. >=20 > This is not a formal AD evaluation. That will occur after the chairs=20 > submit a new publication request. But I think we need to work through=20 > this before it will be ready for IETF last call. >=20 Hello again, Ben, I just posted a new version of the document (an announcement should get to the ML soon) that tries to address most, if not all, of your points. You can find some additional comments inline on the parts I haven't addressed yet (or I only partly addressed), for one reason or another. To make this more readable, I snipped the parts that I already integrated. >=20 > * The intended status is proposed standard. Do people really expect=20 > b2bua vendors to implement the rules in this draft? Do they expect=20 > existing b2bua implementations to be updated? >=20 I already answered to this in my previous mail, but just to reinstate, I'll leave the decision to WG and chairs/ADs as to what the intended status should be. I personally would keep it a proposed standard, but again wouldn't object to a BCP, if needed. >=20 > * Section 3, last paragraph - This paragraph seems to argue that the=20 > fact that > existing b2buas do not follow specs is a reason to create more > specs. That seems > questionable. >=20 Fair point. I haven't changed that part in the doc yet, as I wanted to be sure I'd get it right, first. Do you think it would be ok to say something along the lines of "due to the mixed nature of B2BUAs, they sometimes can't or won't implement all specifications, so they should at least do this"? > * Section 3.1: >=20 > * Second Paragraph > * "but having them synced during setup would > help nonetheless" - Help how? Please elaborate, or > consider dropping the text in the parentheses. >=20 This came up in a STRAW meeting some time ago. The main scenario for that is WebRTC usage, where browsers typically advertize the SSRCs they're going to use in advance. The RTCWEB RTP usage drafts, specifically, mandates support for signalled SSRC identifiers (see Section 4.8), although it also clarifies that endpoints should be prepared to handle SSRCs that were not advertized. The text in the parenthesis wanted to refer to that kind of usage, but I realize the wording was pretty awful, so I dropped it as you suggested. >=20 > * Section 4 > * Last paragraph, 2nd to last sentence - If you think people will=20 > really pay attention, > then this might be a good place for a MUST or SHOULD >=20 Do you mean where we say "behaviour is unspecified and discouraged"? Or more in general about the fact that a B2BUA can only follow the guidelines when it has access to editing fields without breaking hashes? Not sure which MUST or SHOULD we might add there, considering that, if the media the B2BUA is encrypted, it can't possibly edit RTP related information without disrupting the communication, which in turn means no RTCP editing will be needed/possible either. Do you think a "B2BUAs MUST NOT modify RTP/RTCP data if media is encrypted" to be enough, in case? >=20 > * Section 1, First Paragraph: >=20 > * I'm not sure what "... can lead to unexpected situations the > IETF is trying to address" means. It was an awkward attempt at referring to the scope of the STRAW WG itself. I removed the text after "situations". >=20 > * Third paragraph: > * "It SHOULD NOT, though, blindly forward all SDP > attributes,"=20 > - Isn=E2=80=99t > the idea that it should forward any attributes that it=20 > doesn=E2=80=99t > have a specific reason not to forward? (i.e. default to=20 > forwarding?) >=20 The issue here is the reason not to forward itself. In order to figure out whether an attribute can be forwarded or not, the B2BUA must have some knowledge of it and of its impact. What I wanted to highlight in that sentence is that there are attributes that, if left where they are by a B2BUA unaware of their purpose, can actually cause issues. Just think, for instance, of 'rtcp' attribute that is explained in the text, or other attributes supporting features a B2BUA may not support itself. Of course, as you point out there could be reasons to actually keep attributes you don't know about in there, e.g., because they advertize support for an end-to-end feature the B2BUA doesn't need to worry about. Besides, the attributes that can cause issues are probably not that many anyway. I'll think about a way to make this clearer in the next for next version. Thanks! Lorenzo From nobody Tue May 31 17:42:43 2016 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05F712D923; Tue, 31 May 2016 17:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.328 X-Spam-Level: X-Spam-Status: No, score=-108.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ox3dUvV5jyv; Tue, 31 May 2016 17:42:29 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 078D912D931; Tue, 31 May 2016 17:42:04 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id F3FCBB812A3; Tue, 31 May 2016 17:42:03 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160601004203.F3FCBB812A3@rfc-editor.org> Date: Tue, 31 May 2016 17:42:03 -0700 (PDT) Archived-At: Cc: straw@ietf.org, rfc-editor@rfc-editor.org Subject: [straw] RFC 7879 on DTLS-SRTP Handling in SIP Back-to-Back User Agents X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 00:42:42 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7879 Title: DTLS-SRTP Handling in SIP Back-to-Back User Agents Author: R. Ravindranath, T. Reddy, G. Salgueiro, V. Pascual, P. Ravindran Status: Standards Track Stream: IETF Date: May 2016 Mailbox: rmohanr@cisco.com, tireddy@cisco.com, gsalguei@cisco.com, victor.pascual.avila@oracle.com, partha@parthasarathi.co.in Pages: 13 Characters: 29648 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-straw-b2bua-dtls-srtp-12.txt URL: https://www.rfc-editor.org/info/rfc7879 DOI: http://dx.doi.org/10.17487/RFC7879 Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) exist on the signaling and media paths between the endpoints. This document describes the behavior of B2BUAs when Secure Real-time Transport (SRTP) security context is set up with the Datagram Transport Layer Security (DTLS) protocol. This document is a product of the Sip Traversal Required for Applications to Work Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC