Subject: Re: [cuss] Status of cuss documents => purpose parameter value for ISDN

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 9 Nov 2012 00:07:07 +0100

So I am trying to work out how to address this comment from the WGLC.

It is claimed a note is required, but the proposed text contains a normative statement of SHOULD strength, but there is no proposal to update the ABNF.

So I need to ask, what is the proposal. Is it:

1)	to make a normative requirement of SHOULD strength to provide this as a coding capability.

OR

2)	to provide an informative statement that some implementations outside of conformance of this specification, will use this value, and therefore others might want to support it.

It would also be useful to understand what others from the working group want to do.

Regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 09 July 2012 06:54
> To: [email-masked]; DRAGE, Keith (Keith)
> Cc: [email-masked]
> Subject: AW: [cuss] Status of cuss documents => purpose parameter value
> for ISDN
> 
> Hi,
> I can agree on such a note.
> 
> BR
> 
> Roland Jesske
> 
> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im Auftrag von
> [email-masked]
> Gesendet: Donnerstag, 5. Juli 2012 16:44
> An: [email-masked]
> Cc: [email-masked]
> Betreff: Re: [cuss] Status of cuss documents => purpose parameter value
> for ISDN
> 
> Hello,
> 
> Since you may be currently updating the documents with the remarks
> received from WGLC review, I would like to come back again on a topic
> previously discussed (see http://www.ietf.org/mail-
> archive/web/cuss/current/msg00355.html-comment C10 and
> http://www.ietf.org/mail-archive/web/cuss/current/msg00418.html): the
> value of purpose parameter for ISDN.
> Indeed, some implementations are currently generating purpose="isdn-
> interwork" (as indicated in draft-johnston-sipping-cc-uui-08) so this will
> cause a backward compatibility issue because currently in the ISDN draft,
> if present, purpose parameter value MUST be set to "isdn-uui" and, if
> received, its value MUST be set to "isdn-uui", otherwise the header would
> be discarded (as described in sections 7 and 8 of the ISDN draft) and the
> interworking not performed.
> 
> Since some implementations may already be using purpose="isdn-uui", it may
> not be acceptable to simply change it back to purpose="isdn-interwork".
> Therefore, I propose as a compromise to add the following note along the
> line of what has been done in draft-ietf-bfcpbis-rfc4583bis-01 (section 6)
> for BFCP topic:
> 
> Note: 'isdn-interwork' value for purpose parameter was used in Internet-
> Drafts that have led to the publication of the present RFC. Although these
> documents had not other status than "work in progress", it is implemented
> by some vendors. Therefore, it is RECOMMENDED to support parsing and
> interpreting 'isdn-interwork' the same way as 'isdn-uui' when receiving.
> 
> Regards,
> 
> Celine Serrut-Valette
> Orange Labs
> 
> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part de
> Vijay K. Gurbani Envoyé : jeudi 7 juin 2012 16:15 À : [email-masked]
> Objet : [cuss] Status of cuss documents
> 
> Folks: The WGLC date for the two remaining documents has passed.
> 
> The WG received a WGLC review on draft-ietf-cuss-sip-uui-06 courtesy of
> Laura Liess.
> 
> The review for draft-ietf-cuss-sip-uui-isdn-04 is still pending, and
> should be out by next week.
> 
> In the meantime, could the authors of draft-ietf-cuss-sip-uui please start
> to address the WGLC comments and sent out a revision addressing the
> comments?
> 
> To the extent that there are dependencies between these two drafts, I
> suspect that cuss-sip-uui-isdn depends on cuss-sip-uui.  Thus we can start
> preparation for cuss-sip-uui while we wait for the WGLC review of cuss-
> sip-uui-isdn.
> 
> Thanks,
> 
> Vijay K. Gurbani and Enrico Marocco
> 
> _______________________________________________
> 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,
> France Telecom - 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, France Telecom - 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

---

From: <[email-masked]>
Date: Fri, 9 Nov 2012 17:12:44 +0000

Hello,

Thank you for your answer. We would prefer a normative requirement (1/ proposal) to indicate that equipment SHOULD interpret 'isdn-interwork' the same way as 'isdn-uui' when receiving (and even that it MUST interpret it the same way). 
Indeed, informative requirement (2/ proposal) would not be sufficient to ensure that any equipment will correctly interpret 'isdn-interwork' when receiving, what could lead to lose the IUU data if not (in that case the equipment will discard the User-to-User header and for instance if it's a MGCF, it will not perform the SIP/ISUP interworking).
Concerning your comment on ABNF, we followed the same approach as what has been done in draft-ietf-bfcpbis-rfc4583bis-01, that's why we didn't modify the ABNF accordingly, but we agree to update it if you think it is a better way to proceed.

Regards

Celine Serrut-Valette
Orange Labs

-----Message d'origine-----
De : DRAGE, Keith (Keith) [mailto:[email-masked]] 
Envoyé : vendredi 9 novembre 2012 00:07
À : [email-masked]; SERRUT-VALETTE Celine OLNC/OLN
Cc : [email-masked]
Objet : RE: [cuss] Status of cuss documents => purpose parameter value for ISDN

OR

Regards

Keith

> Subject: AW: [cuss] Status of cuss documents => purpose parameter 
> value for ISDN
> 
> Hi,
> Von: [email-masked] [mailto:[email-masked]] Im Auftrag 
> von [email-masked]
> Betreff: Re: [cuss] Status of cuss documents => purpose parameter 
> value for ISDN
> 
> Hello,
> 
> interwork" (as indicated in draft-johnston-sipping-cc-uui-08) so this 
> will cause a backward compatibility issue because currently in the 
> ISDN draft, if present, purpose parameter value MUST be set to 
> "isdn-uui" and, if received, its value MUST be set to "isdn-uui", 
> otherwise the header would be discarded (as described in sections 7 
> and 8 of the ISDN draft) and the interworking not performed.
> 
> Since some implementations may already be using purpose="isdn-uui", it 
> may not be acceptable to simply change it back to purpose="isdn-interwork".
> Therefore, I propose as a compromise to add the following note along 
> the line of what has been done in draft-ietf-bfcpbis-rfc4583bis-01 
> (section 6) for BFCP topic:
> 
> Note: 'isdn-interwork' value for purpose parameter was used in 
> Internet- Drafts that have led to the publication of the present RFC. 
> Although these documents had not other status than "work in progress", 
> it is implemented by some vendors. Therefore, it is RECOMMENDED to 
> support parsing and interpreting 'isdn-interwork' the same way as 'isdn-uui' when receiving.
> 
> Regards,
> 
> Celine Serrut-Valette
> Orange Labs
> 
> De : [email-masked] [mailto:[email-masked]] De la part 
> de Vijay K. Gurbani Envoyé : jeudi 7 juin 2012 16:15 À : [email-masked] 
> The WG received a WGLC review on draft-ietf-cuss-sip-uui-06 courtesy 
> of Laura Liess.
> 
> In the meantime, could the authors of draft-ietf-cuss-sip-uui please 
> start to address the WGLC comments and sent out a revision addressing 
> the comments?
> 
> suspect that cuss-sip-uui-isdn depends on cuss-sip-uui.  Thus we can 
> start preparation for cuss-sip-uui while we wait for the WGLC review 
> of cuss- sip-uui-isdn.
> 
> Thanks,
> 
> ______________________________________________________________________
> ____ _______________________________________________
> 
> 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, France Telecom - 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.

_________________________________________________________________________________________________________________________

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,
France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 9 Nov 2012 18:16:24 +0100

The previous version of BFCPbis exists as a full RFC. So that has the normative definition. The situation is not the same here.

Obviously I still seek other views on this change. 

Keith

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: 09 November 2012 17:13
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]; [email-masked]
> Subject: RE: [cuss] Status of cuss documents => purpose parameter value
> for ISDN
> 
> Hello,
> 
> Thank you for your answer. We would prefer a normative requirement (1/
> proposal) to indicate that equipment SHOULD interpret 'isdn-interwork' the
> same way as 'isdn-uui' when receiving (and even that it MUST interpret it
> the same way).
> Indeed, informative requirement (2/ proposal) would not be sufficient to
> ensure that any equipment will correctly interpret 'isdn-interwork' when
> receiving, what could lead to lose the IUU data if not (in that case the
> equipment will discard the User-to-User header and for instance if it's a
> MGCF, it will not perform the SIP/ISUP interworking).
> Concerning your comment on ABNF, we followed the same approach as what has
> been done in draft-ietf-bfcpbis-rfc4583bis-01, that's why we didn't modify
> the ABNF accordingly, but we agree to update it if you think it is a
> better way to proceed.
> 
> Regards
> 
> Celine Serrut-Valette
> Orange Labs
> 
> It is claimed a note is required, but the proposed text contains a
> normative statement of SHOULD strength, but there is no proposal to update
> the ABNF.
> 
> 2)	to provide an informative statement that some implementations
> outside of conformance of this specification, will use this value, and
> therefore others might want to support it.
> 
> 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,
> information that may be protected by law;

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Nov 2012 10:09:16 -0500

> Obviously I still seek other views on this change.

I don't care one way or the other.

	Thanks,
	Paul