Re: [clue] Opsdir last call review of draft-ietf-clue-signaling-13

I'm part-way through a -14 update and will ensure I review the various issues you raise - thanks very much for the review.

Rob

-----Original Message-----
From: clue <clue-bounces@ietf.org> On Behalf Of Eric Vyncke (evyncke)
Sent: 10 October 2018 19:57
To: Paul Kyzivat <paul.kyzivat@comcast.net>
Cc: clue@ietf.org; draft-ietf-clue-signaling.all@ietf.org
Subject: Re: [clue] Opsdir last call review of draft-ietf-clue-signaling-13

Paul

Thank you for the explanation about the middle boxes, you may want to repeat this text if you make a -14

-éric

On 10/10/2018, 20:39, "Paul Kyzivat" <paul.kyzivat@comcast.net> wrote:

    Éric,

    On 10/10/18 2:10 PM, Éric Vyncke wrote:
    > Reviewer: Éric Vyncke
    > Review result: Has Nits
    > 
    > Reviewer: Eric Vyncke
    > Review result: has minor nits
    > 
    > I have reviewed this document as part of the Operational directorate's ongoing
    > effort to review all IETF documents being processed by the IESG.  These
    > comments were written with the intent of improving the operational aspects of
    > the IETF drafts. Comments that are not addressed in last call may be included
    > in AD reviews during the IESG review.  Document editors and WG chairs should
    > treat these comments just like any other last call comments.
    > 
    >>From a deployment point of view, I liked this introduction statement
    > "Backwards-compatibility is an important consideration of the protocol: it is
    > vital that a CLUE-capable device contacting a device that does not support CLUE
    > is able to fall back to a fully functional non-CLUE call." And special care of
    > co-existence during deployement appear in the document.

    Thanks. It was a critical point for us!

    > But, I wonder how
    > *middle boxes* would react if they are not aware of this protocol extension.

    In general there is no need for existing middle boxes to understand it. 
     From their perspective clue negotiations are just negotiations of sip 
    sessions with multiple media streams. The use of bundle may have more 
    impact on them, but those issues are dealt with as part of the bundle spec.

    Middle boxes that are restrictive, such as forbidding multiple audio or 
    video streams, might cause trouble. But we can't do anything about that.

    Of course it may be possible to imagine a middle box that wants to do 
    something special with clue, but it would need to understand clue to do 
    that.

    	Thanks,
    	Paul

    [Note: I omitted opsdir from the mailing list in my reply in 
    anticipation that it would be rejected because I don't subscribe to it.]

    > Please bear with my very light understanding of CLUE in general. As a side
    > note, it would have been nice to expand the CLUE acronym when used the first
    > time. In general, the document is not easy to read: too many details given
    > immediately without a first high-level description. So, the sections 8 and 9
    > (examples) are really useful even if more details could have been given: for
    > example, while the initial SDP is shown, the response SDP is not.
    > 
    > Nits: section 6 has a reference which does not have a URI.
    > 
    > Else, this document is ready to go.
    > 
    > -éric
    > 
    > _______________________________________________
    > clue mailing list
    > clue@ietf.org
    > https://www.ietf.org/mailman/listinfo/clue
    > 

_______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue