Re: [AVTCORE] Zaheduzzaman Sarker's Discuss on draft-ietf-avtcore-rtp-scip-04: (with DISCUSS and COMMENT)

[Zaheduzzaman Sarker <[e-mail]>]

Hi all,

Now I have cleared my discuss. Thanks for working to resolve the issues.
Good job, all around, special thanks to the chair(s) leading from the
front.

//Zahed

On Wed, Aug 16, 2023 at 4:11 PM [e-mail] <[e-mail]>
wrote:

> Zahed,
>
>
>
> Please refer to Revision 05 since the discussion points below keep
> referring to 04.
>
>
>
> Responses inline below with [DH3].
>
>
>
>
>
> Dan Hanson
> General Dynamics Mission Systems
>
> This message and/or attachments may include information subject to GD
> Corporate Policies 07-103 and 07-105 and is intended to be accessed only by
> authorized recipients.  Use, storage and transmission are governed by
> General Dynamics and its policies. Contractual restrictions apply to third
> parties.  Recipients should refer to the policies or contract to determine
> proper handling.  Unauthorized review, use, disclosure or distribution is
> prohibited.  If you are not an intended recipient, please contact the
> sender and destroy all copies of the original message.
>
>
>
> *From:* Zaheduzzaman Sarker <[e-mail]>
> *Sent:* Tuesday, August 15, 2023 10:10 AM
> *To:* Hanson, Daniel C <[e-mail]>
> *Cc:* Jonathan Lennox <[e-mail]>;
> [e-mail]; [e-mail];
> [e-mail]; [e-mail]; The IESG <[e-mail]>; Faller,
> Michael F <[e-mail]>
> *Subject:* Re: Zaheduzzaman Sarker's Discuss on
> draft-ietf-avtcore-rtp-scip-04: (with DISCUSS and COMMENT)
>
>
>
> *External E-mail *--- CAUTION: This email originated from outside GDMS.
> Do not click links or open attachments unless you recognize the sender and
> know the content is safe.
>
>
>
>
>
>
>
> On Mon, Aug 14, 2023 at 8:39 PM [e-mail] <[e-mail]>
> wrote:
>
> Zaheduzzaman,
>
>
>
> Thank you for your continued discussion of SCIP.  Note that some of points
> relating to Revision 04 below no longer apply because of changes made in
> Revision 05.  We encourage you to download SCIP-210 then review Revision
> 05.  Comments are inline below with [DH2].
>
>
>
>
>
> Regards,
>
> Dan Hanson
> General Dynamics Mission Systems
>
> This message and/or attachments may include information subject to GD
> Corporate Policies 07-103 and 07-105 and is intended to be accessed only by
> authorized recipients.  Use, storage and transmission are governed by
> General Dynamics and its policies. Contractual restrictions apply to third
> parties.  Recipients should refer to the policies or contract to determine
> proper handling.  Unauthorized review, use, disclosure or distribution is
> prohibited.  If you are not an intended recipient, please contact the
> sender and destroy all copies of the original message.
>
>
>
> *From:* Zaheduzzaman Sarker <[e-mail]>
> *Sent:* Friday, August 11, 2023 6:44 AM
> *To:* Jonathan Lennox <[e-mail]>; Hanson, Daniel C <
> [e-mail]>
> *Cc:* [e-mail]; [e-mail];
> [e-mail]; [e-mail]; The IESG <[e-mail]>
> *Subject:* Re: Zaheduzzaman Sarker's Discuss on
> draft-ietf-avtcore-rtp-scip-04: (with DISCUSS and COMMENT)
>
>
>
> *External E-mail *--- CAUTION: This email originated from outside GDMS.
> Do not click links or open attachments unless you recognize the sender and
> know the content is safe.
>
>
>
> Thanks Jonathan for forwarding this email. I lost the thread while
> changing my email address. My responses inline -
>
>
>
> On Wed, Aug 9, 2023 at 12:41 AM Jonathan Lennox <[e-mail]>
> wrote:
>
> Here's the thread in y your discuss on the SCIP draft. Thanks!
>
> ---------- Forwarded message ---------
> From: *[e-mail] <[e-mail]>* <[e-mail]>
> Date: Tue, Feb 7, 2023, 2:15 PM
> Subject: RE: Zaheduzzaman Sarker's Discuss on
> draft-ietf-avtcore-rtp-scip-04: (with DISCUSS and COMMENT)
> To: Zaheduzzaman Sarker <[e-mail]>, The IESG <
> [e-mail]>
> Cc: [e-mail] <
> [e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>, [e-mail]
> <[e-mail]>
>
>
>
> Zaheduzzaman,
>
> Responses are inline below with [DH].
>
>
> Dan Hanson
> General Dynamics Mission Systems
>
> -----Original Message-----
> From: Zaheduzzaman Sarker via Datatracker <[e-mail]>
> Sent: Thursday, January 05, 2023 6:29 AM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: Zaheduzzaman Sarker's Discuss on draft-ietf-avtcore-rtp-scip-04:
> (with DISCUSS and COMMENT)
>
> ----
> External E-mail --- CAUTION: This email originated from outside GDMS. Do
> not click links or open attachments unless you recognize the sender and
> know the content is safe.
>
> Zaheduzzaman Sarker has entered the following ballot position for
> draft-ietf-avtcore-rtp-scip-04: Discuss
>
> 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/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-scip/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Thanks for working on this specification. My understanding is that SCIP is
> not
> a typical audio/video codec and intention here is to defice  a payload
> format
> used along with other audio/video codecs. Thanks to Olivier Bonaventure
> for an
> excellent TSVART review.
>
> I would like to discuss the followings -
>
> - It is not clear to me what RTP profile should be used with this payload
> format. The RTP profiles are mentioned only in the security
> considerations. I
> think this specification would not be sufficient to be implemented without
> specifying the profile usage. I am getting that all the control messages
> are
> sent as SCIP messages, hence it needs to be clear on the RTP/RTCP usage.
>
>
>
> Didn't see any response to this discuss point.
>
>
>
> [DH2] In the Security Consideration section “RTP profile” refers to
> “Profile” AVP, AVPF, SAVP, SAVPF, …
>
> This text was copied from existing RFCs 8130 and 8817.  We will be
> removing “RTP Profile” from the
>
> Introduction section added in Rev 05 and an upcoming Rev 06.
>
>
>
> Yes the security consideration refers to different RTP profiles but that
> is on a different context. i was expecting this specification says this RTP
> format can be used with any RTP profile or list some RTP profiles.  Also
> now that you want to remove "RTP profile" from introduction section, what
> does that supposed to mean?
>
>
>
> [DH3] The first sentence in the section states “… in any applicable RTP
> profile…” so we are unclear what you are asking.  The entire paragraph was
> copied from approved RFCs written in 2017 and 2020.  I don’t understand why
> the text was acceptable then but not now.  The “RTP profile” in the
> Introduction in Revision 05 was in the context of network devices
> implementing packet filtering:
>
>       *Also,  as the SCIP protocol continues to evolve independently of
> this*
>
> *      document, any network device that attempts to filter traffic (e.g.,*
>
> *      deep packet inspection) based on current SCIP traffic profiles may*
>
> *      cause unintended consequences in the future when changes to the
> SCIP*
>
> *      traffic may not be recognized by the network device.*
>
>
>
>
>
>
>
>
> - This statement needs to be clarified more -
>
>     "SCIP traffic is highly variable and the bit rate specified in the SDP
>     [RFC8866] is OPTIONAL since discontinuous transmission (DTX) or other
>     mechanisms may be used."
>
>   What does this "highly variable" traffic mean? In what sense it is
> variable,
>   variable bitrate? if this is highly variable how this would react to
>   congestion and rate control?
>
> [DH] Highly variable is meant to cover all of the control messages
> exchanged that establish a secure session, similar to an IKEv2 exchange.
> Additionally, the encrypted audio stream may also employ DTX.
>
>
>
> Please make is clear in the document. I guess by highly variable you are
> referring both size variation and sending rate variation.
>
>
>
> [DH2] The text referring to “Highly variable” was removed in Rev 05.
>
>
>
> Thanks for the section 3.1. But then section 4 now has "highly variable"
> and "as describe above" is not that helpful there if you are referring to
> the job of the packetizer.
>
>
>
> [DH3] The text was not intended to describe the job of the packetizer,
> rather emphasizing that the SCIP RTP payload contains so many different
> control messages sent at differing intervals as well as various encrypted
> codecs that it is not possible to define a concise format like G.711 or
> G.729.  Perhaps the paragraph could be moved above the diagram to avoid
> confusion.
>
>
>
>
>
>
>
>
>   what bitrate is specified in the SDP? are you talking about the "b"
> parameter
>   and interpretation of that? how is that to be interpreted in the session
>   level and media level due to DTX?
>
> [DH] SDP defines scip/8000 (audio) and scip/90000 (video), the sampling
> rates.  It does not refer to the SDP 'b' parameter.
>
>
>
> would be great to clarify this.
>
>
>
> [DH2] The text referring to “bitrate” was removed in Rev 05.
>
>
>
>
>
>
>
> - it says -
>
>     "a jitter buffer MAY be implemented in endpoint devices only"
>
>   Given that "both discontinuous and continuous traffic are highly
> probable", a
>   jitter buffer is a MAY? How to handle late loss or reordering? is it
> expected
>   that no transmission error possible in the environment where SCIP
> operates?
>
> [DH] We did not want to impose a requirement for a jitter buffer in the
> Endpoint. Implementors can choose whether or not to implement.
>
>
>
> Ok, then this reasoning need to be described. Also there should guidance
> on how to handle late loss or reordering. Also the consequences of having
> jitter buffer or not having jitter buffer should be discussed so that the
> implementers made an educated choice. If there is not impact on the SCIP
> application then that should also be mentioned.
>
>
>
> [DH2] The text referring to “jitter buffer” was removed in Rev 05.
>
>
>
> I don't think removing text here is the appropriate. Rather I would
> suggest to actually make is clear that there is no requirement to have
> jitter buffer. Also network SHOULD NOT repackatize the SCIP packets seems
> like a good recommendation to have.
>
>
>
> [DH3] Rev 05 section 4 last sentence has the text “Network devices MUST
> NOT modify SCIP RTP packets.”.
>
>
>
>
>
>
>
>
> -  what is the plan to include the changes agreed to with the TSVART
> reviewer?
> I mostly agreed with the resolution agreed with the reviewer and would
> like to
> see those changes in the document before we approve this document. That is
> the
> reason I am not bringing those topics back in this discuss. Please consider
> them as my discuss points as well.
>
> [DH] We are planning a few minor updates based on the TSV-ART review.
> However, we are waiting to resolving the comments before posting an update
> to the draft.
>
> Thanks. Please let me know if this done I will check the diff.
>
>
>
> [DH2] Revision 05 was posted on March 29.
>
>
>
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Some further comments -
>
> - Please add a link to SCIP specification, I had hard time finding public
> description or documentation of SCIP codecs.
>
> [DH] The current SCIP-210 specification is not a public document.  For the
> current specification, please request a copy from [e-mail].
> There is a much older version that was posted on
> https://www.iad.gov/SecurePhone/.
>
>
>
> Ok, we are already having bigger discussion on this so let that be
> discussion there.
>
>
>
> [DH2] Please download the SCIP-210 specification.  It should answer many
> of your questions.
>
>
>
> I was referring to Lars's discuss on not publishing this doc as standard
> track as if cannot normatively refer to the SCIP spec.
>
>
>
> [DH3] There is precedence: RFC 8817 (TSVCIS) published in August 2020
> refers to the TSVCIS specification as an Informative Reference.
>
>
>
>
>
>
>
> - I think it would be great to provide the design principles behind SCIP
> with
> some details. This will be helpful for understanding the motivation and rtp
> format specified in the document.
>
> [DH] SCIP-210 defines many of the design considerations.  The primary
> purpose of this RFC is to define SCIP for the internetworking functions
> (SIP Call Managers, SBCs, etc.) so that these devices will allow SCIP to
> traverse their networks as an opaque blob.  The devices do not need to
> attempt to parse the SCIP RTP packets, hence the lack of specificity on the
> exact RTP packet format.
>
>
>
> This I don't believe was very clear to me. May be it is better that this
> explicitly mentioned in the Introduction of this document. Let me know if I
> have missed it somehow. This would have set my mind set differently while
> reviewing this specification.
>
>
>
> [DH2] Revision 05 updated the Abstract, Introduction, and Background to
> reflect this.
>
>
>
> Looks good. However, section 4 might have this repeated.
>
>
>
>
>
>
>
> Many of the internetworking devices are deny-all and do not provide the
> capability to permit the SCIP payload.  It would be next to impossible to
> attempt to list all of the possible RTP packet formats given the numerous
> SCIP call control messages.
>
>
>
> However, I was not asking for a comprehensive list of design principles
> here. As short summery of what are the basic design principles of this SCIP
> would have helped me a lot to understand the potential application usage of
> SCIP message, specially when SCIP specification is not publicly available.
>
>
>
> [DH2] Please download the SCIP-210 specification.  It should answer many
> of your questions.  Bernard suggested thinking of SCIP as a tunneling
> protocol, where other codecs transported in an encrypted channel.  We will
> be adding words to this effect in Rev 06.
>
>
>
> that's a good suggestion. I will then wait for the -06 version.
>
>
>
> [DH3] We were hoping to resolve all issues before posting version 06.
>
>
>
>
>
> //Zahed
>
>
>
>
>
>
>
>