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

From: Ivo Sedlacek <[email-masked]>
Date: Mon, 28 Nov 2016 10:07:49 +0000

Hello,

I noticed that WG state of draft-ietf-ecrit-ecall changed to "Submitted to IESG for Publication" despite a comment (ISSUE 7 in the attached) raised during WGLC was not resolved, even though the issue was confirmed by other people and even though it was requested that the issue is solved before publication request.

I am formally objecting to this state change.

Kind regards

Ivo Sedlacek

Subject: Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 - ISSUE 7
From: Ivo Sedlacek <[email-masked]>
To: Randall Gellens <[email-masked]>, Az Mankin <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Thu, 3 Nov 2016 22:06:48 +0000
List-Id: <ecrit.ietf.org>

Randall,

I identified a technical problem ("attach X to SIP message" is not defined) during WGLC.

You did not solve the technical problem during WGLC.

Paul's mail from 1st Nov somehow confirms that there can be different interpretations and something needs to be done ("It needs to be defined in detail for each case.").

I proposed a possible solution in the updated draft.

You do not like the solution but have not proposed any other solution till now.

The technical problem is still unresolved.

I think I have done my duty and it is time for chairs to settle what to do.

Now in details to your answers:

> >  1) rfc7852 defines "conveying" of data (not "attaching" data):
> >  -------------------
> >     When an emergency call is sent to a Public Safety Answering Point
> >     (PSAP), the originating device, the access network provider to which
> >     the device is connected, and all service providers in the path of the
> >     call have information about the call, the caller, or the location,
> >     which is helpful for the PSAP to have in handling the emergency.
> >     This document describes data structures and mechanisms to **convey such
> >     data** to the PSAP.  The intent is that every emergency call carry as
> >     much of the information described here as possible using the
> >     mechanisms described here.
> >
> >     The mechanisms permit the data to be **conveyed** by reference (as an
> >     external resource) or by value (within the body of a SIP message or a
> >     location object).  This follows the tradition of prior emergency
> >     services standardization work where data can be conveyed by value
> >     within the call signaling (i.e., in the body of the SIP message) or
> >     by reference.
> >  -------------------
> >  so I use "convey" when introducing rfc7852 in eCall draft.
>
> RFC 7852 discusses equally sending data with the call and sending a reference
> to data that is available externally, hence the use of the neutral term
> "conveyance."  I think using "conveyance" in the eCall draft would be less
> well understood by the average reader than using "attach."  The term "attach"
> seems pretty generally well understood, and the current language in the draft
> makes it very clear exactly what steps are performed.

"attach X to SIP message" is NOT defined anywhere and thus the standard is NOT clear.

The nearest interpretation of "attach X to SIP message" is "include a body part containing X with Content-Disposition: attachment in SIP message", which does not work with the draft.

> >  Moreover, given that rfc7852 does not use "attach" data, eCall draft
> > should be able to live without "attach" data too.
> >
> >  2) I *think* the intention of "attach" in the draft is to refer to
> > "block transmitted by value" as described in rfc7852 section 6.1 the
> > last paragraph 1st sentence:
> >  -------------------
> >     When blocks are transmitted by value, the 'purpose' parameter in a
> >     Call-Info header field identifies the data, and the CID URL points to
> >     the data block in the body (which has a matching Content-ID body part
> >     header field).
> >  -------------------
> >  So I use "block transmitted by value" everywhere in eCall draft with
> > exception identified in 3) below.
>
> That seems more confusing to use in the eCall draft, since eCall data is not
> transmitted by reference.

"block transmitted by value" is defined in rfc7852. How can it be confusing to use that term together with referencing rfc7852???

"attach X to SIP message" is NOT defined anywhere.

Can usage of a defined term be more confusing than usage of an undefined term???

Kind regards

Ivo

_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 29 Nov 2016 19:57:00 +0000

Hi,

I also indicated (18th October) that I want to solve the issues before we move the draft forward. There have also been suggestions on how to solve issues. 

Regards,

Christer

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Ivo Sedlacek
Sent: 28 November 2016 12:08
To: [email-masked]
Subject: [Ecrit] Objection to draft-ietf-ecrit-ecall progressing to state "Submitted to IESG for Publication"

Hello,

Kind regards

Ivo Sedlacek

---

From: Brian Rosen <[email-masked]>
Date: Tue, 29 Nov 2016 15:28:23 -0500

I object to your objection.

Despite your characterization, there is no technical issue here.  Everyone agrees on how the mechanism works.  There is an editorial issue on interpreting the word “attached”.  I don’t object to wordsmithing to make it more clear, but it’s not a technical problem and it can be dealt with any time before publication.

Brian

> On Nov 29, 2016, at 2:57 PM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 29 Nov 2016 20:58:03 +0000

Hi,

>I object to your objection.

As far as I remember you did not object when it was initially asked to wait with the publication request before the issue is solved.

>Despite your characterization, there is no technical issue here.  Everyone agrees on how >the mechanism works.  There is an editorial issue on interpreting the word “attached”.  >I don’t object to wordsmithing to make it more clear, but it’s not a technical problem >and it can be dealt with any time before publication.

When is "any time"? A solution has been suggested about a month ago. AFAIK nobody has objected, so please implement it and we're done :)

Regards,

Christer

---

From: Randall Gellens <[email-masked]>
Date: Tue, 29 Nov 2016 15:00:28 -0800

At 3:28 PM -0500 11/29/16, Brian Rosen wrote:

>  Despite your characterization, there is no technical issue here. 
> Everyone agrees on how the mechanism works.  There is an editorial 
> issue on interpreting the word "attached".  I don't object to 
> wordsmithing to make it more clear, but it's not a technical 
> problem and it can be dealt with any time before publication.

I agree and plan to add clarifying wording as part of IETF Last Call.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
As far as the laws of mathematics refer to reality, they are not
certain; and as far as they are certain, they do not refer to reality.
                                                    --Albert Einstein

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 30 Nov 2016 03:40:25 +0000

Hi,

So, exactly what wording do you intend to add?

Regards,

Christer 

Sent from my iPhone

> On 30 Nov 2016, at 1.00, Randall Gellens <[email-masked]> wrote:
> 
>> Despite your characterization, there is no technical issue here. Everyone agrees on how the mechanism works.  There is an editorial issue on interpreting the word "attached".  I don't object to wordsmithing to make it more clear, but it's not a technical problem and it can be dealt with any time before publication.
>

---

From: Ivo Sedlacek <[email-masked]>
Date: Wed, 30 Nov 2016 08:51:27 +0000

Hello,

I also want to see the suggested text before it is added as part of IETF last call (as indicated by Randall). Even if we don’t get the draft back to the WG, I want the WG to agree on the text.

I disagree that there is no technical issue here. "attach X to SIP message" can be understood in different ways, nearest one is to "include X with Content-Disposition: attachment in the SIP message" (which is likely not the intended meaning).

Kind regards

Ivo

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, November 29, 2016 9:28 PM
To: Christer Holmberg <[email-masked]>
Cc: Ivo Sedlacek <[email-masked]>; [email-masked]
Subject: Re: [Ecrit] Objection to draft-ietf-ecrit-ecall progressing to state "Submitted to IESG for Publication"

Brian

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 30 Nov 2016 16:00:23 -0500

I still need to do my AD evaluation of this document and I have four documents total in my queue for review, so the WG can either work this out before I get to the review (likely next week), or I can put a note in my review to await the text proposal.

Alissa

> On Nov 30, 2016, at 3:51 AM, Ivo Sedlacek <[email-masked]> wrote:
> 
> Hello,
>