Re: [cuss] "isdn-uui" versus "isdn-network"

[Atle Monrad <[e-mail]>]

Hi

When this was discussed at IETF-88 it was clearly communicated what people had as an agreement on the cuss-list (due to interop) and this was the starting point of the discussion.

It was also made clear that the parameter (isdn-interwork) had been included in some previous version(s) of the draft and that there were deployments according to this. 

Nevertheless, it was in this discussion found that older versions of parameter names was work-in-progress and was not seen as a strong reason to normatively support both old and new of the parameter names.

----

Below is my understanding of where and when the "isdn-interwork" parameter was visible in the uui-drafts.

Within IETF, it seems that the parameter "isdn-interwork" was normatively introduced in draft-johnston-sipping-cc-uui-08 (June 2009) and remains in draft-johnston-sipping-cc-uui-09 (March 2010). This draft was then discontinued and re-appeared as draft-johnson-cuss-sip-uui. In both versions (-00 and -01) of this draft the "isdn-interwork" appear in the examples only. This  continue in the WG-adopted version draft-ietf-cuss-sip-uui-00. Since draft-ietf-cuss-sip-uui-01 from July 11 2011 I have not been able to find any trace of the parameter "isdn-interwork" in any of the cuss-drafts.

3GPP normally reference the most recent version of internet-draft, thus I cannot find the  "isdn-interwork" referenced in our documentation anymore. 3GPP also Indicates internet-drafts as work-in-progress and indicate this accordingly on our documentation.

I leave to others to decide whether this is sufficient to introduce the normative support of both values or not, but please get the drafts completed one way or another. 

thanks
/atle

________________________________ 


Atle Monrad
3GPP CT Chairman

Group Function Technology - Standardization and Technical Regulation 
Ericsson



-----Original Message-----
From: cuss [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: 27. november 2013 09:37
To: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [cuss] "isdn-uui" versus "isdn-network"

What matters is not whether we call it "normative" or not but the keyword used in the proposed text. The latest proposed wording was using "RECOMMENDED" and most people were happy with this before the "hallway conversation". 
http://www.ietf.org/mail-archive/web/cuss/current/msg00509.html


> -----Message d'origine-----
> De : cuss [mailto:[e-mail]] De la part de 
> [e-mail] Envoyé : mercredi 27 novembre 2013 08:17 À : 
> [e-mail]; [e-mail]; 
> [e-mail]; [e-mail] Objet : Re: [cuss] 
> "isdn-uui" versus "isdn-network"
> 
> Dear all,
> I had no problems in adding a note since such Note has more a 
> guideline function which can be taken into consideration based on 
> bilateral agreements and local policy.
> BUT
> I have problems with the whole discussion about making the "isdn- 
> interworking" now as a normative and mandatory alias or additional 
> element which has now to be understood by all interworking points.
> 
> We have implemented 3GPP TS 29.163 which bases on the latest IETF 
> draft. And this document never stated the "isdn-interworking" has to 
> be used for interworking.
> 
> 
> Best Regards
> 
> Roland
> 
> -----Ursprüngliche Nachricht-----
> Von: cuss [mailto:[e-mail]] Im Auftrag von DRAGE, Keith 
> (Keith)
> Gesendet: Mittwoch, 27. November 2013 03:14
> An: Belling, Thomas (NSN - DE/Munich); Gurbani, Vijay K (Vijay); 
> [e-mail]
> Betreff: Re: [cuss] "isdn-uui" versus "isdn-network"
> 
> I have indicated right at the start of one of the original calls that 
> I would prefer not to make any addition in this area. But putting that 
> aside for the moment.
> 
> In the hallway discussion, I tried to get clarification as to what the 
> change should mean, because I have had several inconstent answers to 
> this in the past. This basically falls into two issues:
> 
> 1)	Whether the change was a note (i.e. normative) or informative. My
> understanding of Bruno's postion was that it should be normative, 
> which means essentially that all implementations recognise the value 
> when it is received. However conformant implementations only generate the correct value.
> It appears however other people were not aware that the change was 
> intended to be normative, based on your continued representation of this as a "NOTE".
> 
> 2)	If the change was normative, then presumably the new value should be
> IANA registered. It was apparently this that caused people to say that 
> they did not want a normative change (which I guess would lead to the 
> impression that the usage was sanctioned for the future), and 
> subsequently that did not see the point of an informative change.
> 
> In response to Christer, when writing the draft, we chose a label that 
> was consistent with the usage it was to be put, which was not to be 
> constrained to interworking with the ISDN, but rather one that 
> provided the equivalent capabilities. We were not aware that we were 
> constrained by examples showing other values in previous drafts; 
> indeed we did not even look at some of those older versions in this 
> respect - at the time this was a new document with a clean field.
> 
> Regards
> 
> Keith
> 
> > -----Original Message-----
> > From: cuss [mailto:[e-mail]] On Behalf Of Belling, 
> > Thomas (NSN - DE/Munich)
> > Sent: 25 November 2013 11:35
> > To: Gurbani, Vijay K (Vijay); [e-mail]
> > Subject: Re: [cuss] "isdn-uui" versus "isdn-network"
> >
> > For me, it is also quite important to finalize the work.
> >
> > I have a certain sympathy for considering backward compatibility, as 
> > I understand that the concerns relate to real deployments and seem 
> > of interest to make things work in reality. I thus support related 
> > wording in the draft.
> >
> > I understand the point that drafts should be regarded as 
> > experimental and subject to change. However, this is only fine if 
> > features demanded in the market are finalized within a reasonable 
> > time. If work goes on for about five years (as in the current case), 
> > backward compatibility will become a real concern no matter if 
> > purists like it. The main takeaway could be to aim to finalize work 
> > in a reasonable amount of time.
> >
> > BR, Thomas
> >
> >
> > ----------------------------------
> > Dr. Thomas Belling
> > 3GPP Standardisation
> > NSN
> >
> >
> >
> > -----Original Message-----
> > From: cuss [mailto:[e-mail]] On Behalf Of ext Vijay K.
> > Gurbani
> > Sent: Friday, November 22, 2013 7:56 PM
> > To: [e-mail]
> > Subject: Re: [cuss] "isdn-uui" versus "isdn-network"
> >
> > On 11/22/2013 12:36 PM, Atle Monrad wrote:
> > > Hi
> > >
> > > I guess each of the "shall we allow multiple
> > representations" needs to
> > > be handled on a case-by-case basis, but generally speaking I 
> > > understand that the chairs and ADs aren't too enthusiastic with 
> > > too many ...
> > >
> > > What 3GPP really wants for Christmas is the draft to be completed.
> > > Somebody must take a decision on this soon.
> >
> > ... which means that by Nov 29, 2013 it'd be nice to hear from 
> > others who have an opinion.
> >
> > Many thanks to those who have already expressed one.
> >
> > Cheers,
> >
> > - vijay
> > --
> > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent 
> > Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
> > Email: vkg@{bell-labs.com,acm.org} / 
> > [e-mail]
> > Web: http://ect.bell-labs.com/who/vkg/  | Calendar:
> > http://goo.gl/x3Ogq _______________________________________________
> > cuss mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/cuss
> > _______________________________________________
> > cuss mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/cuss
> >
> _______________________________________________
> cuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cuss
> _______________________________________________
> cuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cuss

_________________________________________________________________________________________________________________________

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.

_______________________________________________
cuss mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/cuss