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

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 11 Nov 2013 11:38:36 -0600

Folks:

The forward movement of draft-ietf-cuss-sip-uui-isdn has been bogged
down.  While the issue that stopped its movement is not as grandiose
as the MTI discussion on the rtcweb WG (thankfully!), nonetheless, it
must get resolved to proceed further.

At issue is the fact that draft-ietf-cuss-sip-uui-isdn uses the value of
"isdn-uui" for the "purpose" header field parameter.  Older versions of
the draft used the value "isdn-network".  Consequently, there are some
implementations that use "isdn-network" and doubtlessly, for some valid
reasons these implementations are not amenable to change.

Therefore, it was proposed that a note be added that allows senders to
use either "isdn-network" or "isdn-uui" and the receiver be prepared
to receive either of the value.

The big question was whether this note appear as informative or
normative?

If normative, then the ABNF would need to modified to support "isdn-
network" generation as well.  If informative, then this note sets a
precedence that parameters defined in Work In Progress Internet-Drafts
be supported in perpetuity.  The argument for not supporting "isdn-
network" by updating the ABNF is that it introduces a certain amount of
uncertainty: how does a sender decide which representation of the
parameter to send out?  It can randomly choose one, of course, but this
just seems a bad protocol design pattern.

The chairs, the AD, the draft author and a few WG members had a
a hallway conversation in the Vancouver IETF to close this issue.

The outcome of this conversation is that "isdn-network" is an artifact
that draft-ietf-cuss-sip-uui-isdn is NOT required to carry on forward.
Allowing the daft to support an older representation simply sets a
precedent that will engender a tough ride as the draft sails through
the IESG.

As such, "isdn-uui" is the only legal value.

We will now proceed to issue a WGLC on the draft.

Thanks,

Vijay K. Gurbani and Enrico Marocco.

---

From: <[email-masked]>
Date: Wed, 20 Nov 2013 16:51:28 +0000

Vijay,

I don't know who had been invited to the hallway conversation you mentioned but to be honest, I'm really surprised by the decision made. 

Indeed, there were no objections on the cuss list to the latest wording (informative) proposed on Sept 12 for the text to be added to the document and I don't really understand why the proposal was not implemented right away in the I-D actually! 
http://www.ietf.org/mail-archive/web/cuss/current/msg00509.html

Moreover, all people who have been active on this topic on the cuss mailing list either supported the addition of an informative text or have asked questions for clarification. I have not seen any explicit objection.

So, how can a hallway conversation lead to such a U-turn? 

Furthermore, I'd like to understand why people have concerns with adding the proposed informative statement in the CUSS document but seem to be happy with a similar note in draft-ietf-bfcpbis-rfc4583bis

  Note: In [15] 'm-stream' was erroneously used in Section 10.
   Although the example was non-normative, it is implemented by some
   vendors and occurs in cases where the endpoint is willing to act as
   an server.  Therefore, it is RECOMMENDED to support parsing and
   interpreting 'm-stream' the same way as 'mstrm' when receiving.

Bruno

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part de
> Vijay K. Gurbani
> Envoyé : lundi 11 novembre 2013 18:39
> À : [email-masked]
> Objet : [cuss] "isdn-uui" versus "isdn-network"
> 
> Folks:
> 
> The forward movement of draft-ietf-cuss-sip-uui-isdn has been bogged down.
> While the issue that stopped its movement is not as grandiose as the MTI
> discussion on the rtcweb WG (thankfully!), nonetheless, it must get resolved
> to proceed further.
> 
> "isdn-uui" for the "purpose" header field parameter.  Older versions of the
> draft used the value "isdn-network".  Consequently, there are some
> Therefore, it was proposed that a note be added that allows senders to use
> either "isdn-network" or "isdn-uui" and the receiver be prepared to receive
> either of the value.
> 
> The big question was whether this note appear as informative or normative?
> 
> precedence that parameters defined in Work In Progress Internet-Drafts be
> supported in perpetuity.  The argument for not supporting "isdn- network" by
> updating the ABNF is that it introduces a certain amount of
> uncertainty: how does a sender decide which representation of the parameter
> to send out?  It can randomly choose one, of course, but this just seems a
> bad protocol design pattern.
> 
> The chairs, the AD, the draft author and a few WG members had a a hallway
> conversation in the Vancouver IETF to close this issue.
> 
> The outcome of this conversation is that "isdn-network" is an artifact that
> draft-ietf-cuss-sip-uui-isdn is NOT required to carry on forward.
> Allowing the daft to support an older representation simply sets a precedent
> that will engender a tough ride as the draft sails through the IESG.
> 
> _______________________________________________
> cuss mailing list
> [email-masked]
> 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.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 20 Nov 2013 16:48:32 -0600

On 11/20/2013 10:51 AM, [email-masked] wrote:
> Vijay,
>
> I don't know who had been invited to the hallway conversation you
> mentioned but to be honest, I'm really surprised by the decision
> made.

Bruno: Rest assured that no one was explicitly invited or implicitly
precluded in the hallway conversation.  Since the chairs, the AD,
the authors and some working group members were physically at the same
space and time in Vancouver, it seemed appropriate to look into what was
holding the draft back.

> Indeed, there were no objections on the cuss list to the latest
> wording (informative) proposed on Sept 12 for the text to be added to
> the document and I don't really understand why the proposal was not
> implemented right away in the I-D actually!

As to why the proposal of Sept 12 was not implemented in the draft
right away, I will have to defer to the author, but my understanding,
as you write below, is that there was enough of a gray area that
the authors did not quite know how to proceed.

> Moreover, all people who have been active on this topic on the cuss
> mailing list either supported the addition of an informative text or
> have asked questions for clarification. I have not seen any explicit
> objection.
>

The seeming U-turn stems from the fact that either the note being added
be normative or informative.  If informative, then then this note sets a
precedence that parameters defined in Work In Progress Internet-Drafts
be supported in perpetuity.  If normative, then the ABNF has to be
updated and all implementations must not bear the burden of
allocating the same semantic meaning to two syntactically different
headers.  This just seems bad protocol design.

The expedient thing was to take a position and go with WGLC on the
understanding that if the position is not preferable, then this will
be hashed on the mailing list (essentially what we are doing now).

That said, I will take my chair hat off and address what you write
next as an individual contributor.

> Furthermore, I'd like to understand why people have concerns with
> adding the proposed informative statement in the CUSS document but
> seem to be happy with a similar note in
> draft-ietf-bfcpbis-rfc4583bis
>

I have no idea why the bfcpbis working group agreed to alias 'm-stream'
to 'mstrm', but it is certainly their prerogative.  However, does that
mean that we do the same in cuss working group?  Alias header names
just mean that implementations have to add more parsing machinery
to handle the same outcome for a parsed token. Having written a SIP
parser, I am all for making SIP parsing as much deterministic as
possible.

My personal (i.e., not as chair) preference is to have one header name.

Now, back to my role as a chair.

If you'd like to maintain "isdn-network" as an alias for "isdn-uui",
then we need to seek consensus on the list with the understanding that
the note moves to normative and the ABNF is updated to reflect the
alias.  We cannot straddle the fence and simply put a note allowing
"isdn-network" without modifying the ABNF, etc.  This must be done for
the draft to proceed to IESG.

The draft is now in WGLC, and we can certainly handle this change if
the working group agrees as an outcome of WGLC.

Thanks,

- 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} / [email-masked]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

---

From: Andrew Allen <[email-masked]>
Date: Thu, 21 Nov 2013 15:31:50 +0000

I have some sympathy for Bruno's position. He is merely asking to align with the principle of "Be strict in what you send, but generous in what you receive".

I don't think this creates a bad precedent (similar things have been done already - just  take a look at the more complex backwards compatibility being defined now in INSIPID) and whatever is done always requires consensus.

At IETF we hold in high regard running code and hope and expect that people will implement drafts ahead of publication. Given the time this draft has taken to progress it shouldn't be a surprise that there is now deployed equipment based on earlier versions of the draft. In many cases work in IETF has originated based on what was already done outside IETF (e.g. Jabber) and backwards compatibility with pre-standard kit is often a design goal.

I don't think acceptance of a pre-standard  token value is too much to ask to ensure interoperability. That's why we create standards to ensure interoperability not to be an obstacle to it.

Andrew

-----Original Message-----
From: cuss [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, November 20, 2013 11:51 AM
To: Vijay K. Gurbani; [email-masked]
Subject: Re: [cuss] "isdn-uui" versus "isdn-network"

Vijay,

Bruno

> De : [email-masked] [mailto:[email-masked]] De la part 
> de Vijay K. Gurbani Envoyé : lundi 11 novembre 2013 18:39 À : 
> [email-masked] Objet : [cuss] "isdn-uui" versus "isdn-network"
> 
> Folks:
> 
> While the issue that stopped its movement is not as grandiose as the 
> MTI discussion on the rtcweb WG (thankfully!), nonetheless, it must 
> get resolved to proceed further.
> 
> At issue is the fact that draft-ietf-cuss-sip-uui-isdn uses the value 
> of "isdn-uui" for the "purpose" header field parameter.  Older 
> versions of the draft used the value "isdn-network".  Consequently, 
> there are some implementations that use "isdn-network" and 
> doubtlessly, for some valid reasons these implementations are not amenable to change.
> 
> parameter to send out?  It can randomly choose one, of course, but 
> this just seems a bad protocol design pattern.
> 
> The chairs, the AD, the draft author and a few WG members had a a 
> hallway conversation in the Vancouver IETF to close this issue.
> 
> precedent that will engender a tough ride as the draft sails through the IESG.
> 

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
[email-masked]
https://www.ietf.org/mailman/listinfo/cuss
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 21 Nov 2013 11:25:24 -0600

[As individual, of course.]

On 11/21/2013 09:31 AM, Andrew Allen wrote:
>
> I have some sympathy for Bruno's position. He is merely asking to
> align with the principle of "Be strict in what you send, but generous
> in what you receive".

I must say that I disagree.  I suspect that Postel's Law was not
designed to allow multiple tokens to represent the same semantic.
Plus, implementing Postel's Law to the n-th degree leads to brittle
parsers and easy to attack systems.

There is a school of thought that parsers for large and complex
grammars like SIP should be designed using a language-theoretic
approach since these grammars produce essentially a complex
language.  Such complex grammars are PSPACE-complete, making it
daunting to come up with a bullet-proof parser if we keep on
adding multiple ways to represent similar concepts.

But regardless, I don't mean to hammer on this.  If folks feel that
we need to grandfather "isdn-network", that is fine with me.

Thanks,

- vijay

---

From: Andrew Allen <[email-masked]>
Date: Thu, 21 Nov 2013 17:40:17 +0000

Vijay

I don't think we are talking about applying this to the nth degree I think we are simply recognizing that in this case there are deployed systems out there that we ought to attempt to interoperate with if that can relatively easily be achieved..

I am not sure it complicates the parser greatly to have two possible tokens (A or B) as the value of a parameter and then in the call processing logic have an if A or B statement.

Andrew

-----Original Message-----
From: Vijay K. Gurbani [mailto:[email-masked]] 
Sent: Thursday, November 21, 2013 12:25 PM
To: Andrew Allen; [email-masked]; [email-masked]
Subject: Re: [cuss] "isdn-uui" versus "isdn-network"

> align with the principle of "Be strict in what you send, but generous 

I must say that I disagree.  I suspect that Postel's Law was not designed to allow multiple tokens to represent the same semantic.
Plus, implementing Postel's Law to the n-th degree leads to brittle parsers and easy to attack systems.

There is a school of thought that parsers for large and complex grammars like SIP should be designed using a language-theoretic approach since these grammars produce essentially a complex language.  Such complex grammars are PSPACE-complete, making it daunting to come up with a bullet-proof parser if we keep on adding multiple ways to represent similar concepts.

But regardless, I don't mean to hammer on this.  If folks feel that we need to grandfather "isdn-network", that is fine with me.

Thanks,

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Nov 2013 10:39:28 -0800

I don't care enough to take a position either way.

	Thanks,
	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 21 Nov 2013 13:00:57 -0600

On 11/21/2013 11:40 AM, Andrew Allen wrote:
> Vijay
>
> I don't think we are talking about applying this to the nth degree I
> think we are simply recognizing that in this case there are deployed
> systems out there that we ought to attempt to interoperate with if
> that can relatively easily be achieved..
>
> I am not sure it complicates the parser greatly to have two possible
> tokens (A or B) as the value of a parameter and then in the call
> processing logic have an if A or B statement.

Andrew: If you look at the SIP grammar, this obviously will not be the
only header with multiple representations.  We simply keep on adding
to that list.

Beyond that, I think discussing about this to a great degree will not
lead us anywhere.  I am interested in this issue from an academic
point of view, but pragmatism says that we proceed further without
delays.

As an individual, I am happy to allow the draft to proceed with the
alias defined (or not).

Thanks,

- vijay

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 21 Nov 2013 23:51:54 +0000

Hi,

Why did we change the value to begin with? Was the reason pure "cosmetic"?

Anyway, whatever the reason, as the ABNF syntax for the purpose header field parameter value vis "token", a parser should be able to handle also "isdn-network".

Regards,

Christer

________________________________
From: cuss [[email-masked]] on behalf of Vijay K. Gurbani [[email-masked]]
Sent: Thursday, 21 November 2013 9:00 PM
To: Andrew Allen; [email-masked]; [email-masked]
Subject: Re: [cuss] "isdn-uui" versus "isdn-network"

Thanks,

- vijay

---

From: Atle Monrad <[email-masked]>
Date: Fri, 22 Nov 2013 18:36:19 +0000

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.

cheers
/atle

Atle Monrad
3GPP CT Chairman

Group Function Technology - Standardization and Technical Regulation 
Ericsson

-----Original Message-----
From: cuss [mailto:[email-masked]] On Behalf Of Vijay K. Gurbani
Sent: 21. november 2013 20:01
To: Andrew Allen; [email-masked]; [email-masked]
Subject: Re: [cuss] "isdn-uui" versus "isdn-network"

> processing logic have an if A or B statement.

Andrew: If you look at the SIP grammar, this obviously will not be the only header with multiple representations.  We simply keep on adding to that list.

Beyond that, I think discussing about this to a great degree will not lead us anywhere.  I am interested in this issue from an academic point of view, but pragmatism says that we proceed further without delays.

As an individual, I am happy to allow the draft to proceed with the alias defined (or not).

Thanks,

- vijay
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq _______________________________________________

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 22 Nov 2013 12:56:22 -0600

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

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 23 Nov 2013 14:21:25 +0000

Hi,

I already gave some comments, but in case the outcome was clear: I think we should move the draft forward.

Existing entities that implement the old value will anyway have to be updated to support the new value. And, if new entities will have to support the old value, I am sure the buyer will inform the vendor about that :)

Regards,

Christer

From: cuss [[email-masked]] on behalf of Vijay K. Gurbani [[email-masked]]
Sent: Friday, 22 November 2013 8:56 PM
To: [email-masked]
Subject: Re: [cuss] "isdn-uui" versus "isdn-network"

Cheers,

- vijay

---

From: <[email-masked]>
Date: Mon, 25 Nov 2013 08:17:53 +0000

There are many use cases where the calling device sends UUI to a call center but is not expecting any. Such devices (or associated interworking units) would not have to be updated to support the new value.

BC

De : cuss [mailto:[email-masked]] De la part de Christer Holmberg
Envoyé : samedi 23 novembre 2013 15:21
À : Vijay K. Gurbani; [email-masked]
Objet : Re: [cuss] "isdn-uui" versus "isdn-network"

Hi,

Regards,

Christer

From: cuss [[email-masked]] on behalf of Vijay K. Gurbani [[email-masked]]
Sent: Friday, 22 November 2013 8:56 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [cuss] "isdn-uui" versus "isdn-network"

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}<mailto:vkg@%7bbell-labs.com,acm.org%7d> / [email-masked]<mailto:[email-masked]>
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq
_______________________________________________
cuss mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cuss

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 25 Nov 2013 11:34:35 +0000

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:[email-masked]] On Behalf Of ext Vijay K. Gurbani
Sent: Friday, November 22, 2013 7:56 PM
To: [email-masked]
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 

... which means that by Nov 29, 2013 it'd be nice to hear from others who have an opinion.

Cheers,

- vijay

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 27 Nov 2013 02:13:40 +0000

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

> From: cuss [mailto:[email-masked]] On Behalf Of 
> Belling, Thomas (NSN - DE/Munich)
> Sent: 25 November 2013 11:35
> To: Gurbani, Vijay K (Vijay); [email-masked]
> 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
> 
> 
> Web: http://ect.bell-labs.com/who/vkg/  | Calendar: 
> http://goo.gl/x3Ogq _______________________________________________
> cuss mailing list
> [email-masked]

---

From: <[email-masked]>
Date: Wed, 27 Nov 2013 08:17:28 +0100

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:[email-masked]] Im Auftrag von DRAGE, Keith (Keith)
Gesendet: Mittwoch, 27. November 2013 03:14
An: Belling, Thomas (NSN - DE/Munich); Gurbani, Vijay K (Vijay); [email-masked]
Betreff: Re: [cuss] "isdn-uui" versus "isdn-network"

Regards

Keith

> From: cuss [mailto:[email-masked]] On Behalf Of Belling, Thomas 
> (NSN - DE/Munich)
> 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
> 
> 
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, 
> Rm. 9C-533, Naperville, Illinois 60563 (USA)

---

From: <[email-masked]>
Date: Wed, 27 Nov 2013 08:37:28 +0000

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

> De : cuss [mailto:[email-masked]] De la part de [email-masked]
> Envoyé : mercredi 27 novembre 2013 08:17
> À : [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> 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
> 
> 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
>

---

From: Atle Monrad <[email-masked]>
Date: Thu, 28 Nov 2013 11:27:16 +0000

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

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

> De : cuss [mailto:[email-masked]] De la part de 
> [email-masked] Envoyé : mercredi 27 novembre 2013 08:17 À : 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked] 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
> 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
> 
> 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.
> 
> change should mean, because I have had several inconstent answers to 
> this in the past. This basically falls into two issues:
> 
> 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".
> 
> 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
> 
> > From: cuss [mailto:[email-masked]] On Behalf Of Belling, 
> > Thomas (NSN - DE/Munich)
> > 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.
> >
> > 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
> >
> >
> > > understand that the chairs and ADs aren't too enthusiastic with 
> > > too many ...
> > >
> > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent 
> > Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)