Re: [Gen-art] Genart last call review of draft-ietf-sipcore-originating-cdiv-parameter-05

Vijay Gurbani <vijay.gurbani@gmail.com> Mon, 05 November 2018 17:57 UTC

Return-Path: <vijay.gurbani@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9349127133; Mon, 5 Nov 2018 09:57:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OB3KjTwZRCnQ; Mon, 5 Nov 2018 09:57:20 -0800 (PST)
Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0662C12008A; Mon, 5 Nov 2018 09:57:20 -0800 (PST)
Received: by mail-oi1-x234.google.com with SMTP id k64-v6so8233612oia.13; Mon, 05 Nov 2018 09:57:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AwqgtH5kpAxm/t4mN8UfCdv6ej9BrkEUXrLWwkO5XU8=; b=Ed+ijdKQHRjiygC01xMVe6p4ZvcGGvdnqE7i09hV3NmKIMumCHeS1YyiLSeqpBchka OdlGzFP6aRINqBYu91LHDJa7d9BFFiR0wEXqByIZY9BvkSa2Un6texFgXV/c4I35/5rw Ayd6tIujGGMKL4CL8hQouy6tckzXwkAUsBSUCSXy5QbJ7yNodJwFmCkPvZ6c7PwqEsbi uThcumbTo2NV4uI+CktgJxcPy6zGhgAba3umwykVMPb1PpT9vGvJmpoAgxfrRP71vJCn XxykyvwmNjP4saXRdEEHE6/NlvWhoDPvaCAqSvZYjYBOszLU/92YehDSqKkBq0Iea1S+ eYLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AwqgtH5kpAxm/t4mN8UfCdv6ej9BrkEUXrLWwkO5XU8=; b=jXWcEnliHmlrXBHCicSsxE+qmRwU+7lCUKwMqKePVE4k1t9EjL5y0PC9p6pMHFeULp YbYbqSm87RdZEfilaSwyK2J1Aisu0j4qUeZ00CVRW2qR9XL17jrQseu15wovUJAaKVr+ 7zeVghW2OZyP37P2PuQh6G2ey2SMUrHs1ljINAyaB/W4DZ2KoW6aXzbvZNF4E+xHFv8P cLoUaIegqKuPZoYQ93IPvgE55fkTrV7SBj+lUfN1omsn1aFELw/tkbErVMaWzdVbA8YK KCYpQ6rO0CLbeVko9fpWp7UxEsJRik7BbvaTeXAj+qwkil3SthPOh1+U3LMgMiDdJ0vt XDig==
X-Gm-Message-State: AGRZ1gLayaShkOTYABcOdPiHbdhbxPlEpdlAqst2Fxs+YeCdrxhHfXe/ 2TaInjotMKstFKzCA/DB4MbuGESiig3kzfiIluY=
X-Google-Smtp-Source: AJdET5cqR6NUHURqNS/iOYLVzbyRK4eYONigAdnEBI6GWvywtntln72PzUv+JEKtz0UW81wQrHdkvCqawOqNw+m+mj4=
X-Received: by 2002:aca:c1d7:: with SMTP id r206-v6mr14066849oif.44.1541440639133; Mon, 05 Nov 2018 09:57:19 -0800 (PST)
MIME-Version: 1.0
References: <154084621265.4963.11856647404649644525@ietfa.amsl.com> <26344_1541435406_5BE0700E_26344_158_14_8B970F90C584EA4E97D5BAAC9172DBB84A2558EC@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <CAMMTW_Ly35VdhH3bfHvYdFVijLTuS1hYJTyoFMzT99T=i7YhCg@mail.gmail.com> <19441_1541437458_5BE07812_19441_188_1_8B970F90C584EA4E97D5BAAC9172DBB84A255B4D@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <CAMMTW_LF61b0BrTtigK0A8nAsMZCt6=W_Y=8CoDM2z5_fR_4-g@mail.gmail.com> <21449_1541440262_5BE08306_21449_405_1_8B970F90C584EA4E97D5BAAC9172DBB84A255C43@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
In-Reply-To: <21449_1541440262_5BE08306_21449_405_1_8B970F90C584EA4E97D5BAAC9172DBB84A255C43@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
From: Vijay Gurbani <vijay.gurbani@gmail.com>
Date: Mon, 05 Nov 2018 11:57:07 -0600
Message-ID: <CAMMTW_K9Vhib_Dksfv0QCVE4-Gq0Auj4goYF6Vt2wski-feDLw@mail.gmail.com>
To: marianne.mohali@orange.com
Cc: gen-art@ietf.org, sipcore@ietf.org, ietf@ietf.org, draft-ietf-sipcore-originating-cdiv-parameter.all@ietf.org, Jean Mahoney <mahoney@nostrum.com>, ben@nostrum.com
Content-Type: multipart/alternative; boundary="000000000000bcedc50579ee9d8f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/qJdNRj4wpM2T10MIG8c1YtCCy8k>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-sipcore-originating-cdiv-parameter-05
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Nov 2018 17:57:24 -0000

Dear Marianne: OK, if the context of "originating after CDIV" is well
understood by the folks working in this area, then I am fine with leaving
it as is.
Thanks.
- vijay

On Mon, Nov 5, 2018 at 11:51 AM <marianne.mohali@orange.com> wrote:

> Dear Vijay,
>
>
>
> Actually, the « originating » is not qualifying something by itself in
> this sentence, it has to be understood as a global wording for the new
> defined session case which is "originating after CDIV" which is different
> for an “originating call leg”.
>
>
>
> If you don’t mind, I would prefer to keep this wording as it is because it
> is used although the I-D and quoted in the Introduction section in the
> following sentence:
>
> "The sessioncase-param parameter of the P-Served-User header field is
> extended with the "orig-cdiv" parameter for this "originating after CDIV"
> session case."
>
>
>
> Marianne
>
>
>
> *De :* Vijay Gurbani [mailto:vijay.gurbani@gmail.com]
> *Envoyé :* lundi 5 novembre 2018 18:14
> *À :* MOHALI Marianne TGI/OLN
> *Cc :* gen-art@ietf.org; sipcore@ietf.org; ietf@ietf.org;
> draft-ietf-sipcore-originating-cdiv-parameter.all@ietf.org; Jean Mahoney;
> ben@nostrum.com
> *Objet :* Re: Genart last call review of
> draft-ietf-sipcore-originating-cdiv-parameter-05
>
>
>
> Dear Marianne: Thank you, again, for attending to my comment.
>
>
>
> Note that you still have a dangling verb "originating" in the sentence.
> The verb is not qualifying anything:
>
>
>
>    For this use case, this document creates a new parameter ("orig-cdiv")
> for
>    the originating after CDIV session case to be embedded in the
> P-Served-User
>    header field.
>
>
>
> In my email, I had suggested adding "call leg" after the "originating"
> above.  Otherwise, the sentence above is incomplete ... "originating" what?
>
>
>
> Thanks.
>
>
>
>
>
> On Mon, Nov 5, 2018 at 11:04 AM <marianne.mohali@orange.com> wrote:
>
> Thanks Vijay for your last feedback. I’m fine with your proposal and have
> updated the I-D accordingly (v-07):
>
> https://datatracker.ietf.org/doc/draft-ietf-sipcore-originating-cdiv-parameter/
>
> BR,
> Marianne
>
> De : Vijay Gurbani [mailto:vijay.gurbani@gmail.com]
> Envoyé : lundi 5 novembre 2018 17:45
> À : MOHALI Marianne TGI/OLN
> Cc : gen-art@ietf.org; sipcore@ietf.org; ietf@ietf.org;
> draft-ietf-sipcore-originating-cdiv-parameter.all@ietf.org
> Objet : Re: Genart last call review of
> draft-ietf-sipcore-originating-cdiv-parameter-05
>
> Dear Marianne: Thank you for attending to my comments.
>
> I am fine with the text you added for S1.3.
>
> Regarding "secase" and "regstate" being existing parameters, ok.  However,
> since the I-D is defining the "orig-cdiv" parameter, I still think it makes
> sense to mention this before S4.  You already have the text at the end of
> S1.3 (the current sentence appears ambiguous).  Let me suggest an edit:
>
> OLD:
> For this use case, this document creates a new parameter for the
>    originating after CDIV session case to be embedded in the P-Served-
>    User header field.
>
> NEW:
> For this use case, this document creates a new parameter ("orig-cdiv") for
> the
>    originating call leg to be embedded in the P-Served-User header field.
> Thanks.
>
> On Mon, Nov 5, 2018 at 10:30 AM <marianne.mohali@orange.com> wrote:
> Hi all,
>
> Thanks Vijay for the GenArt review.
> I've just submitted a v-06 to address your comments and here is my
> feedbacks:
>
> https://datatracker.ietf.org/doc/draft-ietf-sipcore-originating-cdiv-parameter/
>
> >Minor:
> >
> >- S1.3: I am not sure I follow the logic in the problem statement.  Who
> > is the "diverting" user?  The user to who the call was destined?  If so,
> > best to say that explicitly.  (To be sure, I looked into rfc5502 as well,
> > and it does not define "diverting" user either.)  A bit below (in S4),
> you
> > use the term "served" user to refer to the diverting user.  All in all,
> the
> > terminology here could be refined.  I suspect that the "originating"
> user
> > is the callee.
> >
> > Concretely, I think that the first paragraph of S1.3 should be
> re-written,
> > perhaps with a figure (?) to explain the call flow, or at least some
> > context using Alice, Bob and Carol as the example in S7.1 does (I suspect
> > that Carol is the "diverting" user here).
>
> [MM] Indeed, I can see that for people not very aware of IETF and 3GPP
> vocabulary for call diversion service, it can be confusing. I prefer not to
> add a call flow in the problem statement section but I did some updates in
> the wording and inserted the Alice, Bob and Carol users for a better
> understanding.
>
> >Nits, typos:
> >
> >- S4, step 3: s/user an INVITE that/user as an INVITE that/
> > Also, the "secase" and "regstate" parameters are what you are
> standardizing
> > this I-D, as such you mention this before S4 so the reader knows that
> > these are the new parameters.  Same for "orig-cdiv" parameter.
>
> [MM] Nits is corrected. About your comment, actually, this I-D is only
> standardizing "orig-cdiv" parameter. This is the reason why "sescase" and
> "regstate" appear, as part of a normal session establishment and before any
> call diversion while the new parameter can appear only when this event
> occurs (as added by this I-D).. I hope it's clearer for you.
>
> I hope it's ok.
>
> Best regards,
> Marianne
>
> -----Message d'origine-----
> De : Vijay Gurbani [mailto:vijay.gurbani@gmail.com]
> Envoyé : lundi 29 octobre 2018 21:50
> À : gen-art@ietf.org
> Cc : sipcore@ietf.org; ietf@ietf.org;
> draft-ietf-sipcore-originating-cdiv-parameter.all@ietf.org
> Objet : Genart last call review of
> draft-ietf-sipcore-originating-cdiv-parameter-05
>
> Reviewer: Vijay Gurbani
> Review result: Almost Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
> Document: draft-ietf-sipcore-originating-cdiv-parameter-??
> Reviewer: Vijay K. Gurbani
> Review Date: 2018-10-29
> IETF LC End Date: 2018-10-26
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: This draft is on the right track but has open issues, described
> in the review.
>
> Major issues: 0
>
> Minor issues: 1
>
> Nits/editorial comments: 1
>
> Minor:
>
> - S1.3: I am not sure I follow the logic in the problem statement.  Who
>  is the "diverting" user?  The user to who the call was destined?  If so,
>  best to say that explicitly.  (To be sure, I looked into rfc5502 as well,
>  and it does not define "diverting" user either.)  A bit below (in S4),
> you
>  use the term "served" user to refer to the diverting user.  All in all,
> the
>  terminology here could be refined.  I suspect that the "originating" user
>  is the callee.
>
>  Concretely, I think that the first paragraph of S1.3 should be re-written,
>  perhaps with a figure (?) to explain the call flow, or at least some
>  context using Alice, Bob and Carol as the example in S7.1 does (I suspect
>  that Carol is the "diverting" user here).
>
> Nits, typos:
>
> - S4, step 3: s/user an INVITE that/user as an INVITE that/
>  Also, the "secase" and "regstate" parameters are what you are
> standardizing
>  this I-D, as such you mention this before S4 so the reader knows that
>  these are the new parameters.  Same for "orig-cdiv" parameter.
>
>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
>