Re: [Ecrit] Objection to draft-ietf-ecrit-ecall progressing to state "Submitted to IESG for Publication"

[Ivo Sedlacek <[e-mail]>]

Hello Randall,

thanks for the updates.

> >  viii)
> >  Proposed change: replace "To do so, the PSAP creates a 
> > metadata/control object requesting an MSD and attaches it to a SIP 
> > INFO request and sends it within the dialog." with "To do so, the PSAP 
> > creates a metadata/control object requesting an MSD, includes it to a 
> > SIP  INFO request as per [RFC6086] and sends it within the dialog.".
> >  Reason: There has been discussion in past on whether rfc7852 is 
> > needed in SIP INFO request or not as sematic of the bodies associated 
> > with info package is defined in the info package itself.
> > IIRC, the conclusion was:
> >  - rfc7852 is not needed; and
> >  - to align with how body parts are sent in an INFO request and in 
> > messages other than INFO requests, a Call-Info header field inclusion 
> > is added in SIP INFO request - see 2nd paragraph of section 10.6.
> 
> I changed "attach" to "include".  Note that the paragraph already says:
>     Per
>     [RFC6086], metadata/control objects and MSDs are sent using the INFO
>     package defined in Section 10.  In addition, to align with how an MSD
>     or metadata/control block is transmitted in a SIP message other than
>     an INFO request, a Call-Info header field is included in the SIP INFO
>     request to reference the MSD or metadata/control block per [RFC7852].
> 
> I believe this makes it very clear that (a) everything sent within INFO is 
> done per RFC6086, and (b) the use of Call-Info is done for consistency with 
> non-INFO messages.

If I understood it correctly, the text will be: "To do so, the PSAP creates a metadata/control object requesting an MSD and includes it to a SIP INFO request and sends it within the dialog."
if so, that's OK with me.
Thanks.

> >  ix)
> >  Proposed change: replace "The IVS then attaches an updated MSD to a 
> > SIP INFO request and sends it within the dialog." with "The IVS then 
> > includes an updated MSD to a SIP INFO request as per [RFC6086] and 
> > sends it within the dialog.".
> >  Reason: same reason as for the previous proposed change.
> 
> As above, I changed "attach" to "include" but the reference to RFC
> 6086 is within the same paragraph and covers this sentence so doesn't need to 
> be repeated.

If I understood it correctly, the text will be: "The IVS then includes an updated MSD to a SIP INFO request and sends it within the dialog."
if so, that's OK with me.
Thanks.

> >  x)
> >  Proposed change: extend "If the IVS is unable to send an MSD, it 
> > instead sends a metadata/control object acknowledging the request 
> > with the 'success' parameter set to 'false' and a 'reason' 
> > parameter (and optionally a 'details' parameter) indicating why the 
> > request could not be accomplished." with additional text "as per 
> > [RFC6086]".
> >  Reason: RFC6086 is to be used both when request to send MSD is 
> > accepted and when it is rejected.
> 
> As above.

OK.

> >  It would be also nice to fix the following minor issues:
> >  - "INVITE" is used in some places where "INVITE request" should be.
> >  - "method" is missing is some places.
> >  However, those are nice-to-have and not critical.
> 
> I fixed cases where "request" was missing.  If you point out cases 
> where "method" is missing I can fix them as part of IETF LC.

IMO, "method" should be used in section 10.2 as follows:
----------------------
10.2.  Applicability

   This section describes "why the Info Package mechanism, rather than
   some other mechanism, has been chosen for the specific use-case...."

   The use of INFO >>method<< is based on an analysis of the requirements against
   the intent and effects of INFO >>method<< versus other approaches (which
   included SIP MESSAGE >>method<<, SIP OPTIONS >>method<<, SIP re-INVITE >>method<<, media plane
   transport, and non-SIP protocols).  In particular, the transport of
   emergency call data blocks occurs within a SIP emergency dialog, per
   Section 6, and is normally carried in the initial INVITE  >>request<<and its
   response; the use of INFO >>method<< only occurs when emergency-call-related
   data needs to be sent mid-call.  While MESSAGE >>method (or request?)<< could be used, it is
   not tied to a SIP dialog as is INFO >>method (or request?)<< and thus might not be associated
   with the dialog.  SIP OPTIONS >>method (or request?)<< or re-INVITE  >>method (or request?)<< could also be used, but is
   seen as less clean than INFO >>method (or request?)<<.  SUBSCRIBE/NOTIFY  >>methods (or requests?)<< could be coerced into
   service, but the semantics are not a good fit, e.g., the subscribe/
   notify mechanism provides one-way communication consisting of (often
   multiple) notifications from notifier to subscriber indicating that
   certain events in notifier have occurred, whereas what's needed here
   is two-way communication of data related to the emergency dialog.
   Use of the media plane mechanisms was discounted because the number
   of messages needing to be exchanged in a dialog is normally zero or
   very few, and the size of the data is likewise very small.  The
   overhead caused by user plane setup (e.g., to use MSRP as transport)
   would be disproportionately large.

   Based on the the analyses, the SIP INFO method was chosen to provide
   for mid-call data transport.
----------------------

Kind regards

Ivo Sedlacek