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

[<[e-mail]>]

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 : [e-mail] [mailto:[e-mail]] De la part de
> Vijay K. Gurbani
> Envoyé : lundi 11 novembre 2013 18:39
> À : [e-mail]
> 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.
> 
> 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.
> _______________________________________________
> 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.