Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4583bis

[Tom Kristensen <[e-mail]>]

Answers inline.

On 19 July 2017 at 01:37, Roman Shpount <[e-mail]> wrote:

> Hi All,
>
> I have reviewed the document and have the following comments:
>
> Section 8 BFCP Connection Management:
>
> It specifies that BFCP can use TCP or UDP as underlying transport. It does
> not specify what happens when ICE, TCP/DTLS/BFCP, TCP/TLS/BFCP, or
> UDP/TLS/BFCP are used. I suggest to explicitly specify that ICE,
> TCP/DTLS/BFCP, and UDP/TLS/BFCP follow the same procedures for connection
> management as UDP/BFCP. TCP/TLS/BFCP follows the same procedures as TCP/BFCP
>

TK: :) Yes, stating just that for a clear definition of behaviour to use
and expect.


> Section 9 Authentication:
>
> Not sure why we are talking about SIP here. I think we should restate
>
> When SDP is used to perform an offer/answer exchange, the initial mutual
> authentication takes place at the SIP level. Additionally, SIP uses S/MIME
> [6] to provide an integrity-protected channel with optional confidentiality
> for the offer/answer exchange.
>
> as
>
> When SDP is used to perform an offer/answer exchange, the initial mutual
> authentication SHOULD take place at the signaling level. Additionally,
> signaling can use S/MIME [6] to provide an integrity-protected channel with
> optional confidentiality for the offer/answer exchange.
>

 TK: :) Yes, we may very well generalize from stating SIP to use the term
signaling (of some sort).


> This section specifies that "This implies that unless a 'fingerprint'
> attribute is included in the session description, the certificate provided
> at the TLS-/DTLS-level MUST either be directly signed by one of the other
> party's trust anchors or be validated using a certification path that
> terminates at one of the other party's trust anchors [5]". I thought
> "fingerprint" attribute are required and certificate signature by trust
> anchor is irrelevant.
>
> Not sure what "When using UDP, the procedure above was preferred since it
> adheres to [16] as used for DTLS-SRTP" means, especially since [16} is not
> specific to SRTP-DTLS, but specifies generic rules for all DTLS based
> protocols. The whole logic is circular since it proposes to follow
> procedures from [16] since they are compliant with procedures from [16].
>

TK: I'm currently trying to remember the background for this text, it was
altered and added in one of the many rounds earlier on. I agree that this
is not clear and a bit confusing.


> Section 10. ICE Considerations
>
> Please synchronize text with text in https://tools.ietf.org/html/
> draft-ietf-mmusic-sctp-sdp-26#section-12.2 . This section was updated
> during WGLC for draft-ietf-mmusic-sctp-sdp, so it would make sense to
> synchronize those changes here. Let me know if you need help with this.
>

TK: I'll draft a sketch of this.


>
> Regards,
>
> _____________
> Roman Shpount
>
> On Mon, Jul 17, 2017 at 4:10 AM, Charles Eckel (eckelcu) <
> [e-mail]> wrote:
>
>> (As WG co-chair)
>>
>> This is a reminder that WGLC ends tomorrow. I realize the time to review
>> overlaps with IETF prep and meeting times. If you require more time to
>> review the draft, please let me know. Otherwise, please share your review
>> comments by the end of tomorrow.
>>
>> Thanks,
>> Charles
>>
>> -----Original Message-----
>> From: bfcpbis <[e-mail]> on behalf of Charles Eckel <
>> [e-mail]>
>> Date: Wednesday, July 5, 2017 at 5:59 PM
>> To: "[e-mail]" <[e-mail]>
>> Subject: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4583bis
>>
>>     (As WG co-chair)
>>
>>     This is to announce an additional working group last call for
>> draft-ietf-bfcpbis-rfc4583bis, "Session Description Protocol (SDP) Format
>> for Binary Floor Control Protocol (BFCP) Streams".
>>     http://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4583bis/
>>
>>     This is intended as a Standards Track RFC, obsoleting RFC 4583.
>>     Please respond to the list by July 18th (i.e. 2 weeks) with any
>> comments.
>>
>>     We had a working group last call previous, but a significant amount
>> of time and some substantial changes and additions have occurred to justify
>> another review of the draft in its entirely. It is helpful to attempt to
>> categorize your comment (e.g. technical issue vs. editorial), and also to
>> provide any replacement text you feel is necessary.
>>     If you review the document and have no comments, please tell the
>> chairs that you have reviewed it. This is always useful information in
>> assessing the degree of WG review and consensus behind the document.
>>     Note, we have not scheduled a working group session for IETF 99 in
>> Prague. This WGLC will close during IETF 99. If helpful, we can arrange a
>> side meeting to discuss any significant issues, or with any luck, gather at
>> a bar to celebrate the draft being ready to advance to the next step toward
>> RFC.
>>
>>     Cheers,
>>     Charles
>>
>>
>>     _______________________________________________
>>     bfcpbis mailing list
>>     [e-mail]
>>     https://www.ietf.org/mailman/listinfo/bfcpbis
>>
>>
>>
>
> _______________________________________________
> bfcpbis mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bfcpbis
>
>


-- 
# http://folk.uio.no/tomkri/ | [phone] (m)
## http://facebook.com/tomkri/ | xmpp:[e-mail]
### "Å leve er å ta stilling. Jeg hater likegyldige mennesker.", A. Gramsci