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:cuss-bounces@ietf.org] De la part de R.Jesske@telekom.de
> Envoyé : mercredi 27 novembre 2013 08:17
> À : keith.drage@alcatel-lucent.com; thomas.belling@nsn.com;
> vijay.gurbani@alcatel-lucent.com; cuss@ietf.org
> 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:cuss-bounces@ietf.org] Im Auftrag von DRAGE, Keith (Keith)
> Gesendet: Mittwoch, 27. November 2013 03:14
> An: Belling, Thomas (NSN - DE/Munich); Gurbani, Vijay K (Vijay);
> cuss@ietf.org
> 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:cuss-bounces@ietf.org] On Behalf Of Belling, Thomas
> > (NSN - DE/Munich)
> > Sent: 25 November 2013 11:35
> > To: Gurbani, Vijay K (Vijay); cuss@ietf.org
> > 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:cuss-bounces@ietf.org] On Behalf Of ext Vijay K.
> > Gurbani
> > Sent: Friday, November 22, 2013 7:56 PM
> > To: cuss@ietf.org
> > 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} / vijay.gurbani@alcatel-lucent.com
> > Web: http://ect.bell-labs.com/who/vkg/  | Calendar:
> > http://goo.gl/x3Ogq _______________________________________________
> > 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
> >
> _______________________________________________
> 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

_________________________________________________________________________________________________________________________

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.