Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3981A88CE for ; Wed, 27 May 2015 06:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFl31HX_RzJz for ; Wed, 27 May 2015 06:00:43 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6BC11A88BE for ; Wed, 27 May 2015 06:00:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoEIALq+ZVXGmAcV/2dsb2JhbABcgkUhKiMxXgEFhSKqIgwBAQEBAQEGkzgdAQiFeAKBOkwBAQEBAQGBC4QkAQEDEhtMEgEVBw5WJgEEDg0aiAsBDKEornUBAQEBAQEBAwEBAQEBAQEBGoYWiXggDQSCNAxBHYEWBZMIhDWIAz6DM4J0jyEjYXyCG3ABAYFDgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,505,1427774400"; d="scan'208,217";a="118140067" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 27 May 2015 09:00:41 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 27 May 2015 09:00:40 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Wed, 27 May 2015 09:00:39 -0400 From: "Romascanu, Dan (Dan)" To: General Area Review Team Thread-Topic: Gen-ART Review for draft-ietf-xmpp-6122bis Thread-Index: AdCYfR4I1nAAPOSWRKWL/2RPfmKruA== Date: Wed, 27 May 2015 13:00:38 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CA3C683@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5CA3C683AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-xmpp-6122bis.all@tools.ietf.org" Subject: [Gen-art] Gen-ART Review for draft-ietf-xmpp-6122bis X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GEN-ART: General Area Review Team" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 13:00:47 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5CA3C683AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am the assigned Gen-ART reviewer for this draft. For background on Gen-AR= T, please see the FAQ at >. Please resolve these comments along with any other Last Call comments you m= ay receive. Document: https://art.tools.ietf.org/tools/art/genart/index.cgi/t=3D965/doc= ?selected_doc=3Ddraft-ietf-xmpp-6122bis Reviewer: Dan Romascanu Review Date: 5/27/15 IETF LC End Date: 6/3/15 IESG Telechat date: Summary: Ready with one issue which I believe is worth discussing. Major issues: I have a concern about backwards compatibility and migration. In the migrat= ion between 6122 and 6122bis deployments it is possible that previously-val= id JIDs might no longer be valid or previously-invalid JIDs become valid. B= ecause of this the Introduction says that operators of XMPP services are ad= vised to perform careful testing before migrating accounts and other data. In a dialog with Peter Saint-Andre (document author) I asked if there are = any recommendations that could be made to the application designers and ope= rators respectively to ease the migration? His answer pointed to section 6 (actually I think that 6.1 applies) in in d= raft-ietf-precis-saslprepbis. I believe that a pointer to that section in a= 'migration / backwards compatibility' section would be useful for the appl= ication designers. What about the operators, however? Can more details abou= t what operator should test to ensure compatible migration of users and app= lications be provided beyond what is mentioned in the introduction? Minor issues: Nits/editorial comments: --_000_9904FB1B0159DA42B0B887B7FA8119CA5CA3C683AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am the assigned Gen-ART reviewer for this draft= . For background on Gen-ART, please see the FAQ at

 

<http://wiki.tools.= ietf.org/area/gen/trac/wiki/GenArtfaq>.

 

Please resolve these comments along with any othe= r Last Call comments you may receive.

 

Document: https://art.tools.ietf.org/tools/art/ge= nart/index.cgi/t=3D965/doc?selected_doc=3Ddraft-ietf-xmpp-6122bis

Reviewer: Dan Romascanu

Review Date: 5/27/15

IETF LC End Date: 6/3/15

IESG Telechat date:

 

Summary:

 

Ready with one issue which I believe is worth dis= cussing.

 

Major issues:

 

I have a concern about backwards compatibility an= d migration. In the migration between 6122 and 6122bis deployments it is po= ssible that previously-valid JIDs might no longer be valid or previously-in= valid JIDs become valid. Because of this the Introduction says that operators of XMPP services are advised to = perform careful testing before migrating accounts and other data.

 

In a dialog with Peter Saint-Andre (document auth= or) I asked if  there are any recommendations that could be made to th= e application designers and operators respectively to ease the migration?

 

His answer pointed to section 6 (actually I think= that 6.1 applies) in in draft-ietf-precis-saslprepbis. I believe that a po= inter to that section in a ‘migration / backwards compatibility’= ; section would be useful for the application designers. What about the operators, however? Can more details about what = operator should test to ensure compatible migration of users and applicatio= ns be provided  beyond what is mentioned in the introduction?

 

Minor issues:

 

Nits/editorial comments:

 

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5CA3C683AZFFEXMB04globa_--