Re: [cuss] alignment between draft-ietf-cuss-sip-uui-isdn-10 and draft-ietf-cuss-sip-uui-17

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Mon, 10 November 2014 21:25 UTC

Return-Path: <keith.drage@alcatel-lucent.com>
X-Original-To: cuss@ietfa.amsl.com
Delivered-To: cuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B553F1A1BB5 for <cuss@ietfa.amsl.com>; Mon, 10 Nov 2014 13:25:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.494
X-Spam-Level:
X-Spam-Status: No, score=-7.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] autolearn=ham
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 NhBVJAZjXB0M for <cuss@ietfa.amsl.com>; Mon, 10 Nov 2014 13:24:54 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E81B51A1BB4 for <cuss@ietf.org>; Mon, 10 Nov 2014 13:24:53 -0800 (PST)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id E5B07920ABE2A; Mon, 10 Nov 2014 21:24:48 +0000 (GMT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id sAALOq2i012876 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Nov 2014 22:24:52 +0100
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.25]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 10 Nov 2014 22:24:52 +0100
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: Atle Monrad <atle.monrad@ericsson.com>, "cuss@ietf.org" <cuss@ietf.org>
Thread-Topic: [cuss] alignment between draft-ietf-cuss-sip-uui-isdn-10 and draft-ietf-cuss-sip-uui-17
Thread-Index: Ac/9KIKPEA8Ax3YPQZaYIudPpM8XtwAA+q7A
Date: Mon, 10 Nov 2014 21:24:51 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B276D78@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <7D2F7D7ADBA812449F25F4A69922881C168F9F3B@ESESSMB203.ericsson.se>
In-Reply-To: <7D2F7D7ADBA812449F25F4A69922881C168F9F3B@ESESSMB203.ericsson.se>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.38]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/cuss/100IIYzcIoBtCzPHQLCNqXDT6tY
Subject: Re: [cuss] alignment between draft-ietf-cuss-sip-uui-isdn-10 and draft-ietf-cuss-sip-uui-17
X-BeenThere: cuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" <cuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cuss>, <mailto:cuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cuss/>
List-Post: <mailto:cuss@ietf.org>
List-Help: <mailto:cuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cuss>, <mailto:cuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Nov 2014 21:25:01 -0000

I thought I was very clear on the ones that are now wrong. In summary - you cannot make consistent something that is the name of a parameter in a protocol that IETF does not own, or in a service definition that IETF does not own. As such, you just end up referencing to some concept that does not exist.

This is the list of changes that need to be reverted:

Appears a number of changes deviate from the terminology in other documents, and should therefore be undone.
 
So the correct terminology is as follows:
 
1)    "User-user information element" see ITU-T recommentation Q.931 and ITU-T Q.957.1 for correct usage, making the following changes incorrect:
 
-    Abstract
-    Section 2
 
2)    "User-to-user signalling supplementary service" see ITU-T Recommendation Q.957.1 for correct usage, making the following changes incorrect:
 
-    Section 3 (Title)
-    Section 3.1 many times
-    Section 13 (twice)
 
3)    Q.763 "User-to-user information" see ITU-T Recommendation Q.763 for correct usage, making following changes incorrect.
 
-    Section 2
 
4)    Within the ISDN supplementary service "User-to-user information" or "user-to-user data".
 
-    Section 3.1 many times
-    Section 6
 
5)    In section 14 please write out name of service in full as in 2) above.
 
6)    Additionally section 14 would probably be better to write (instead of "User to User package"):
 
"UUI package" which is the terminology in draft-ietf-cuss-sip-uui.
  

> -----Original Message-----
> From: cuss [mailto:cuss-bounces@ietf.org] On Behalf Of Atle Monrad
> Sent: 10 November 2014 20:59
> To: cuss@ietf.org
> Subject: [cuss] alignment between 
> draft-ietf-cuss-sip-uui-isdn-10 and draft-ietf-cuss-sip-uui-17
> 
> Folks
> 
> On June 23rd, I asked some questions to 
> draft-ietf-cuss-sip-uui-isdn-09, and one of the questions 
> was: "It is not clear to me if the way this draft use the 
> permutations of the term "user to user", i.e.  'user to 
> user', 'User to User', 'User-to-User' and 'User-to-user' have 
> any logic. If so, I'd be happy to understand it..."
> 
> A few days ago ...  version -10 of the draft came out, where 
> the new version of the draft attempted to align the terms as 
> "User to User Information" and "User-to-User header field".
> 
> After this, it has been some off-list discussions whether 
> this usage of these terms is correct or not.
> 
> My 1st priority is to get the cuss-drafts completed, as 3GPP 
> is still waiting for the drafts to be completed. 
> I do not mind the alignment too much, but as I find 
> consistent use of terminology useful, I have compared the 
> draft-ietf-cuss-sip-uui-isdn-10 and draft-ietf-cuss-sip-uui-17.
> 
> Between draft-ietf-cuss-sip-uui-isdn-10 and 
> draft-ietf-cuss-sip-uui-17, I find the usage of "User to User 
> Information" and "User-to-User header field" quite 
> consistent, EXCEPT 3 instances  of "user-to-user information" 
> in section "8.1.  Why INFO is Not Used" of draft-ietf-cuss-sip-uui.
> 
> IMHO  the two drafts are aligned at present (with the fixes  
> of "user-to-user information" in draft-ietf-cuss-sip-uui-17). 
> If it is a wish to revert a number of the terms in 
> draft-ietf-cuss-sip-uui-isdn-10, I think the authors should 
> have a look at draft-ietf-cuss-sip-uui-17 as well for alignment.
> 
> I have also had a look at RFC6567, which is consistent in the 
> use of the term "User-to-User", thus it is an option to 
> consistently use the terms "User-to-User Information" AND 
> "User-to-User header field" in both drafts, and be in line 
> with the requirements-RFC :-)
> 
> In addition, both drafts use terms like UUI data, UUI 
> service, UUI content parameters, UUI application, UUI header 
> field, UUI mechanism, etc .... in a similar fashion, thus I 
> do not think anything  is needed to do in this area. 
> 
> At last I have an additional comments that I think you must 
> take onboard in draft-ietf-cuss-sip-uui-isdn AND in 
> draft-ietf-cuss-sip-uui unless you can justify the current text.
> 
> In draft-ietf-cuss-sip-uui, the terms "UUI package" and 
> "package" is used a bit in a mix. It start off as "UUI 
> package" and move towards "package" possibly due to making 
> the text read a bit easier. I think that the term "UUI 
> package" is rather easy to do use consistently and should be 
> a quick fix in all instances where you target mentioning the 
> UUI package and not package in general.
> 
> In draft-ietf-cuss-sip-uui-isdn, the terms used are 
> "package", "UUI package" and "ISDN package". To me it seems 
> that these terms are not used aligned and correct. While the 
> draft may wish to refer to some instances of "package" (in 
> general) the "UUI package" (generally for any UUI-packages) 
> and e.g. the "ISDN-UUI package" (specifically), I think you 
> need to review the descriptive text and decide on what term 
> to use where. This is also why I think you should correct the 
> draft-ietf-cuss-sip-uui WRT the term "package" versus "UUI 
> package" to have alignment between the two drafts.
> 
> I hope that these changes can be taken onboard in new 
> revisions of the drafts as soon as possible. It is not my 
> intention to send the drafts into another 3-month cycle 
> waiting for new versions. If the current authors have no time 
> for making a quick update, I propose that new authors 
> (assumed found ...) that are willing do the needed 
> corrections by a defined deadline can be assigned.
> 
> Cheers
> /atle
> 
> ________________________________ 
> 
> 
> Atle Monrad
> 3GPP CT Chairman
> 
> Group Function Technology - Standardization and Technical 
> Regulation Ericsson
> 
> 
> 
> -----Original Message-----
> From: cuss [mailto:cuss-bounces@ietf.org] On Behalf Of 
> internet-drafts@ietf.org
> Sent: 24. oktober 2014 13:35
> To: i-d-announce@ietf.org
> Cc: cuss@ietf.org
> Subject: [cuss] I-D Action: draft-ietf-cuss-sip-uui-isdn-10.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
>  This draft is a work item of the Call Control UUI Service 
> for SIP Working Group of the IETF.
> 
>         Title           : Interworking ISDN Call Control User 
> Information with SIP
>         Authors         : Keith Drage
>                           Alan Johnston
> 	Filename        : draft-ietf-cuss-sip-uui-isdn-10.txt
> 	Pages           : 16
> 	Date            : 2014-10-24
> 
> Abstract:
>    The motivation and use cases for interworking and 
> transporting ITU-T
>    DSS1 User to User information element data in SIP are described in
>    RFC 6567.  As networks move to SIP, it is important that 
> applications
>    requiring this data can continue to function in SIP 
> networks as well
>    as the ability to interwork with this ISDN service for end-to-end
>    transparency.  This document defines a usage (a new package) of the
>    User-to-User header field to enable interworking with this ISDN
>    service.
> 
>    This document covers the interworking with both public ISDN and
>    private ISDN capabilities, so the potential interworking with QSIG
>    will also be addressed.
> 
>    The package is identified by a new value "isdn-uui" of the 
> "purpose"
>    header field parameter.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui-isdn/
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-cuss-sip-uui-isdn-10
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-cuss-sip-uui-isdn-10
> 
> 
> Please note that it may take a couple of minutes from the 
> time of submission until the htmlized version and diff are 
> available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> cuss mailing list
> cuss@ietf.org
> https://www.ietf.org/mailman/listinfo/cuss
> 
> _______________________________________________
> cuss mailing list
> cuss@ietf.org
> https://www.ietf.org/mailman/listinfo/cuss
>