From dime-bounces@ietf.org Sat Mar 1 10:13:36 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD9063A6CCC; Sat, 1 Mar 2008 10:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.646 X-Spam-Level: X-Spam-Status: No, score=-1.646 tagged_above=-999 required=5 tests=[AWL=0.791, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saKrPuuvOUeo; Sat, 1 Mar 2008 10:13:36 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F6543A6806; Sat, 1 Mar 2008 10:13:36 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 639113A6CB3 for ; Sat, 1 Mar 2008 10:13:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DiQLSu9+1p3 for ; Sat, 1 Mar 2008 10:13:34 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id A8DE83A6806 for ; Sat, 1 Mar 2008 10:13:33 -0800 (PST) Received: (qmail invoked by alias); 01 Mar 2008 18:13:24 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp017) with SMTP; 01 Mar 2008 19:13:24 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19jjzcjc+5jAy8ARZ9Dr56T3Y95IEKM7cNW8SZ5EZ qv+gF615XPNzdj Message-ID: <47C99CC4.1080009@gmx.net> Date: Sat, 01 Mar 2008 20:13:24 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: dime@ietf.org Content-Type: multipart/mixed; boundary="------------030509030206060902020208" X-Y-GMX-Trusted: 0 Subject: [Dime] Media Independent Handover & draft-stupar-dime-mos-options-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --------------030509030206060902020208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Folks, I got some information from the IETF MIPSHOP chairs regarding a recently submitted draft: draft-stupar-dime-mos-options-00.txt ---- The MIPSHOP WG is working on a solution for a mobile node to discover 802.21 MIH servers when the mobile node attaches to an access router. Part of the solution involves delivering the MIH server information from a AAA server to the NAS on the access link. DHCP is then used to deliver the information to the mobile node. We need the DIME WG's help in completing the Diameter extensions for this. The IEEE 802.21 WG is very interested in the MIH work we are doing in the IETF. They have sent a couple of liaison statements to the MIPSHOP WG saying they want this work completed in the IETF. I have attached one liaison letter we got from them recently. --- I told the MIPSHOP chairs that it would be nice to get a bit of information about the Media Independent Handover work so that DIME working group members are able to judge the specific solution. Ciao Hannes --------------030509030206060902020208 Content-Type: application/pdf; name="21-07-0286-00-0000-Liaison-to-IETF-MIPSHOP-from-802-21-Jul-2007.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename*0="21-07-0286-00-0000-Liaison-to-IETF-MIPSHOP-from-802-21-Jul-2"; filename*1="007.pdf" JVBERi0xLjQNJeLjz9MNCjkgMCBvYmogPDwvTGluZWFyaXplZCAxL0wgMTY0OTMvTyAxMi9F IDEwODQ3L04gMi9UIDE2MjY3L0ggWyA3MzYgMTg0XT4+DWVuZG9iag0gICAgICAgICAgICAg ICAgICAgDQp4cmVmDQo5IDIyDQowMDAwMDAwMDE2IDAwMDAwIG4NCjAwMDAwMDA5MjAgMDAw MDAgbg0KMDAwMDAwMDczNiAwMDAwMCBuDQowMDAwMDAwOTk3IDAwMDAwIG4NCjAwMDAwMDEx NzUgMDAwMDAgbg0KMDAwMDAwMTMwNyAwMDAwMCBuDQowMDAwMDAxNjgxIDAwMDAwIG4NCjAw MDAwMDIyMjQgMDAwMDAgbg0KMDAwMDAwMjI1OCAwMDAwMCBuDQowMDAwMDAyNTAzIDAwMDAw IG4NCjAwMDAwMDI3NDIgMDAwMDAgbg0KMDAwMDAwMjgxOCAwMDAwMCBuDQowMDAwMDAzNDE0 IDAwMDAwIG4NCjAwMDAwMDQwMTUgMDAwMDAgbg0KMDAwMDAwNDU5NyAwMDAwMCBuDQowMDAw MDA1MjM3IDAwMDAwIG4NCjAwMDAwMDU4NTMgMDAwMDAgbg0KMDAwMDAwNjQwNiAwMDAwMCBu DQowMDAwMDA2Nzg2IDAwMDAwIG4NCjAwMDAwMDc0MDQgMDAwMDAgbg0KMDAwMDAwNzkyMyAw MDAwMCBuDQowMDAwMDEwNTkyIDAwMDAwIG4NCnRyYWlsZXINCjw8L1NpemUgMzEvUHJldiAx NjI1Ny9Sb290IDEwIDAgUi9JbmZvIDggMCBSL0lEWzxhNDBiZTUxYjQ3ZTgxOWMwZjhiYzFi ZGJiNmExN2MzNz48OGRjNmU0OWE3NmQyOTU0NGExMjgzYzdlYjExMDM5N2M+XT4+DQpzdGFy dHhyZWYNCjANCiUlRU9GDQogICAgICAgICAgICAgICANCjExIDAgb2JqPDwvTGVuZ3RoIDEw NC9GaWx0ZXIvRmxhdGVEZWNvZGUvTCAxMTQvUyA1OD4+c3RyZWFtDQp42mJgYGAGIl0GVgYG NgEGPgYE4APKMDOwMHA0MDSuYGD4wsDAGvkBKJ7AAOYjAWEoZmBQYuDhZEgSdfzLwHCZ54KW spK5klOcShK76CIPuShv3gsQ9SwMDPrbgTQTEFsABBgAK4APag0KZW5kc3RyZWFtDWVuZG9i ag0xMCAwIG9iajw8L1BhZ2VzIDYgMCBSL1R5cGUvQ2F0YWxvZy9QYWdlTGFiZWxzIDQgMCBS L01ldGFkYXRhIDcgMCBSPj4NZW5kb2JqDTEyIDAgb2JqPDwvQ29udGVudHNbMjAgMCBSIDIx IDAgUiAyMiAwIFIgMjMgMCBSIDI0IDAgUiAyNSAwIFIgMjcgMCBSIDI4IDAgUl0vVHlwZS9Q YWdlL1BhcmVudCA2IDAgUi9Sb3RhdGUgMC9NZWRpYUJveFswIDAgNjEyIDc5Ml0vQ3JvcEJv eFswIDAgNjEyIDc5Ml0vUmVzb3VyY2VzIDEzIDAgUj4+DWVuZG9iag0xMyAwIG9iajw8L0Nv bG9yU3BhY2U8PC9DczYgMTYgMCBSPj4vRm9udDw8L1RUMiAxNCAwIFIvVFQ0IDE1IDAgUi9U VDYgMjYgMCBSPj4vUHJvY1NldFsvUERGL1RleHRdL0V4dEdTdGF0ZTw8L0dTMSAxOSAwIFI+ Pj4+DWVuZG9iag0xNCAwIG9iajw8L1R5cGUvRm9udC9FbmNvZGluZy9XaW5BbnNpRW5jb2Rp bmcvQmFzZUZvbnQvVGltZXNOZXdSb21hblBTLUJvbGRNVC9GaXJzdENoYXIgMzIvTGFzdENo YXIgMTE5L1N1YnR5cGUvVHJ1ZVR5cGUvRm9udERlc2NyaXB0b3IgMTcgMCBSL1dpZHRoc1sy NTAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAyNTAgMjc4IDUwMCA1MDAgNTAwIDAgMCAw IDAgMCA1MDAgMCAzMzMgMCA1NzAgMCA1NzAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDQ0NCAw IDUwMCA1NTYgMjc4IDAgMCAwIDAgMCA1MDAgNTU2IDAgNDQ0IDAgMzMzIDAgMCA3MjJdPj4N ZW5kb2JqDTE1IDAgb2JqPDwvVHlwZS9Gb250L0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9C YXNlRm9udC9UaW1lc05ld1JvbWFuUFNNVC9GaXJzdENoYXIgMzIvTGFzdENoYXIgMTUwL1N1 YnR5cGUvVHJ1ZVR5cGUvRm9udERlc2NyaXB0b3IgMTggMCBSL1dpZHRoc1syNTAgMCAwIDUw MCAwIDAgMCAwIDMzMyAzMzMgMCA1NjQgMjUwIDMzMyAyNTAgMjc4IDUwMCA1MDAgNTAwIDUw MCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAyNzggMjc4IDU2NCAwIDU2NCAwIDkyMSA3MjIg NjY3IDY2NyA3MjIgNjExIDU1NiA3MjIgNzIyIDMzMyAzODkgMCA2MTEgODg5IDcyMiA3MjIg NTU2IDAgNjY3IDU1NiA2MTEgNzIyIDcyMiA5NDQgNzIyIDcyMiAwIDAgMCAwIDAgMCAwIDQ0 NCA1MDAgNDQ0IDUwMCA0NDQgMzMzIDUwMCA1MDAgMjc4IDI3OCA1MDAgMjc4IDc3OCA1MDAg NTAwIDUwMCA1MDAgMzMzIDM4OSAyNzggNTAwIDUwMCA3MjIgNTAwIDUwMCA0NDQgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDMzMyAwIDAgMCA1MDBd Pj4NZW5kb2JqDTE2IDAgb2JqWy9JQ0NCYXNlZCAyOSAwIFJdDWVuZG9iag0xNyAwIG9iajw8 L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udEJCb3hbLTU1OCAtMzA3IDIwMDAgMTAyNl0vRm9u dE5hbWUvVGltZXNOZXdSb21hblBTLUJvbGRNVC9GbGFncyAzNC9TdGVtViAxMzYvQ2FwSGVp Z2h0IDY1Ni9YSGVpZ2h0IDAvQXNjZW50IDg5MS9EZXNjZW50IC0yMTYvSXRhbGljQW5nbGUg MC9Gb250RmFtaWx5KFRpbWVzIE5ldyBSb21hbikvRm9udFN0cmV0Y2gvTm9ybWFsL0ZvbnRX ZWlnaHQgNzAwPj4NZW5kb2JqDTE4IDAgb2JqPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250 QkJveFstNTY4IC0zMDcgMjAwMCAxMDA3XS9Gb250TmFtZS9UaW1lc05ld1JvbWFuUFNNVC9G bGFncyAzNC9TdGVtViA4Mi9DYXBIZWlnaHQgNjU2L1hIZWlnaHQgMC9Bc2NlbnQgODkxL0Rl c2NlbnQgLTIxNi9JdGFsaWNBbmdsZSAwL0ZvbnRGYW1pbHkoVGltZXMgTmV3IFJvbWFuKS9G b250U3RyZXRjaC9Ob3JtYWwvRm9udFdlaWdodCA0MDA+Pg1lbmRvYmoNMTkgMCBvYmo8PC9U eXBlL0V4dEdTdGF0ZS9TQSBmYWxzZS9PUCBmYWxzZS9TTSAwLjAyL29wIGZhbHNlL09QTSAx Pj4NZW5kb2JqDTIwIDAgb2JqPDwvTGVuZ3RoIDUyNy9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0 cmVhbQ0KSIl0k01z2jAQhu/+FXu0O5UsyfrsdHpoIA2ZpmUG3ZgeKAjqTMAZ2wnTf9+VjTHN x2Bk2Wh33/fZJf+24LBrkq8+yb0XwMFvEy6A4QdvjoFhlloJfp8w2OHXr+NyTFLI/H0Mkn1Q ftVoWDd9JDTrAx4jnHIMnYyHTxX6VERqygs1HugjLl74D+9uxsqkiDHSUNfVYpQxVkSdZNge k2U6r6v7sG4hI0JJls6m0ylYJqjgcBc25Qpmh014DLgcWrhZHTbVc6hhEernch0ayH752wsD imqholqtu5ojls+duNcwqDL4MOgTMWCZ/mnbx095fjweM0NlSssQQhRV1btc8LwrOvXYEE2V BF04KtB0YWiBt8i2Dsk2Nm9smdAFtRa05NQMXUu/dMgwExLH34yNuhW3lElgVBrn7DnVCHZM qpATaK6iipgzWtBnxFz3iH3ZPgQEXEjL0+/lqmyqA7QVzKb+Gu5m88XNzzls62qfWTQ70B9M 9tIKQZW9kGYZe8tlJ0hZ5KHPgngUVOAb57pOTK5+gOCEGcKE1YQxvHA5CSNtFZlgIcnURWf0 uZXLlKDyTKPW64xTm5KTB3L2QDIcAZmiE/LKCdO0eI/xSyNaUCeikXSyasPL/0LH2PQTs3j6 vc8cVWnZtmHTl+yHcThNRhjDDmFwB7dPD38/gmDM/DcNyjjq3poG+CfAANqf6zsNCmVuZHN0 cmVhbQ1lbmRvYmoNMjEgMCBvYmo8PC9MZW5ndGggNTMyL0ZpbHRlci9GbGF0ZURlY29kZT4+ c3RyZWFtDQpIiWySW2+cMBCF3/0r5tG0WdfGF2CfmpAmaqVtH4q2lZo+WIRsnLBLBHtJ/33H hg1su0ICS8wZn5nzPZCrgogYOD740THzr5ilCoo14YxzLqEoCYfiQOj3ZteW1R3t7iKIiiei mYk1cCYzDcU1mR3rsXTp9tUz3O5etjaUcpgJFoeyUJX5rrPj8UB+0c+bbRUpltAa8qZ9adpI sozarWs2EP0uvvQtjBp7qLGH6nvEMeewcF3nRXlT19WqgqsoYYo2u7ra2/b+YtpsYjsOYw4n P6vdoPW8tq29gPwSMs21CqMIwwROopgevIwLWjaurObvBSieQoLtk8SYs/PHb95F8E5v7Osc pkqdiqAs3gWFGG9ZWFdvm3n4+yHvDJRdHyB05YZI5uM8+qJ7HwRbsZWP4qPDJdesbNZe+6kg UuMWQGWYpEEA0KLBPA3397UVeTjFQyVIhi9PmE4DILAiFIZeyrAUtMxYih+RMgyFM5X6cP5v FUhTKEmMb0TP8RTGniwq7kNeuPLRVpFGUG4Z/IgEp66unV1HGe0ivJJOIp6sXI+46LDHr82z s/Dtz9N0z5NkBhKkkHBjXVs+uvoerltc6IlAjgI5OGx2CI/bwBLR09RFaCSj1aEHSXEle4cD SZIl58AYrg9MQWDDaA5pLIELBOQfqnqJeKNY9FRd/uylKc6ssgxEJtMT94lXwF8BBgAyEOug DQplbmRzdHJlYW0NZW5kb2JqDTIyIDAgb2JqPDwvTGVuZ3RoIDUxMy9GaWx0ZXIvRmxhdGVE ZWNvZGU+PnN0cmVhbQ0KSImMk0uPmzAUhff8iru0pWL5wcPMqq2SqqkUddR4V3XBEJPQYXBk nKb99zV2EjJRK42QwBjb9zvnXFJKKKUlqFPyHa3rrnfmAV6wJDnqcMr8o9nXuic7cur6vqvj pxGnOWHo/WCeu5o0Js4C/qG+JEuVZAWRkBXC33MmCc2AkqysKglWJ23yUSWMA/WXf+SccBCy IJyDekkCTgaqSdIwrCLZN/0AOBWVzH2dzfFwMNZBayysluoTrFePm89fH2Ftnrq+c39go+2v rtEjKFsPY1i8wCUpkMb+WInGbjeA0kENR3Ay9vkOngrCi7fS5xWpsit9NdHTiRt9eBqdrRsH WP1MGCX+jLAxjBirSAmi8EDz5jzqVftuhK1pjpFQDw78RA29dk5bcGYWjqckvPp3oH8frB7H btiB22sYzzaZ1i9eLkFSD8ugxQUyU7QS2bAuCKfgZ7jw5RcRhM8qzvYGDVflrCiJyEBkJeHy ii/n5GRU8joUDyvRbTJhwk44HLmIcu+ToJKUxV0lFvDOzTLVWejbUIVvRt+iGdJtGzwYYIsF KVFYNTm0XuFiMg7cpUVi8Zto/fHytuzsCAmBXppFlMXE+cZm8RFc3GKzWyyqeDzagxl9Jiln OUXKwKiH7b+Dnzq+tf7fK0mFzhHjNPMvMehXDS1EgPsPI/wVYABpEP78DQplbmRzdHJlYW0N ZW5kb2JqDTIzIDAgb2JqPDwvTGVuZ3RoIDU3MS9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVh bQ0KSIl0U02P0zAUvOdX+Ggj1YrdZJPcqRAcOEXiQPeQD7fJwsaVky6CX8/7aoADWmlje96b mTd2nVc5/DmvSm+98k1hK5871b5muc3zvFbtkOWq/ZHpz3Gbh6BM+5I5wKSRVs41tlLH3Nuy 3lsdtcLKFdj/VbfTvCrzpMc4mCdb6/urcc6WOiybmroVENWHQNBiDt42GqtviY9u5mid7lIY 1RYVla/zuqltClj28XQ64bfOzXP7KfPONjVabN9nB7Jz3O3UbAfmddjxJaZv83LF5YcU7zdL dJsCs/FyQfFCJ/6MqFtaMNphUd+BA3WJSZHmQUQPzrqiqVCa9CpUZhOepcfZFDDMOtzXdTaQ odMRTiqc29kj0Jsa5GQ3EoSC0mYcWljoOHLNRojqhW0ZH4vr3hy5QXHpxH1BDSQl8owl1unp 7E7/GeBzyEoWBMkwb6I4ShfRd98JO+v1bMgDgclAGk9sKkGehb7KwEz1q/tbTiZksbPmXuCj RqtaU8Hr2MeBN0XvxHhAtyCjiI/dN6f8TxKPbCtyhvfZvvvzdOjWImZV0rs9Wo/vFno8s3q6 Foh3xcBq3b+EQeANg/E8B2yZZOJdR5vlGugrTItUQj6XSGxJJFW3jELAgFjYrTDfBUMqtWAQ RakTsbG3JI6mgOmD7MqVjI6s/pM21uSYFIbcPDzT722Ii7AkNt1T/Z1LmE8mZhG+uZIShns0 vFMMssc1pDcO4j/FTPuwwZGlmW1cJ4nAPKvfAgwAo80eew0KZW5kc3RyZWFtDWVuZG9iag0y NCAwIG9iajw8L0xlbmd0aCA1NDcvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJVFNN j9sgEL37V8wRpASBjT+i3qrmsHtsfav2QGyyduXFEXG66r/vzICVVpEMDDNvHm9e+tdCw9Eo Y6sW+m+FVlqbGvoBw/1n8VNsslInsUrMqQW4UVpcx4Ns8PAhTYmXPoyA5zXKWpUCPmcuSYVT yo9Odnj3KY8ag5ALnSwxmBI972OqdQsvMKwh3boUD55huN3ko5/liaKJnAL51r8W576wjeqg Mka1DdSmU9qCVrbDl0H0xbX42hemBI0/XGrsC6VF3BL6DxZAn0gA8d0v3t09yP5XYTCeS3hn zEm1UNaN0h2XsWRZPNKtnzwMslEtaleJsMX58tjWSMzfUQ26QN6V2O7gKHiN3nP0kKXG2Byj /70OKfuyeFjmwQdktKEMloZSifToUqtWNw3SyzPEp+6EbB7kRPidgJczrqXYv5pmtq0wI2ZN nGgywxpva3Sbp1ERHSePNNzNx9ktaS6U7ubgx/9LYZvmO9mDiR13Zuyx09NjDfE77lSJIIMa TR6w4oK+acSDtLDoECsouKZj4LsDMjdoQuxdJQtYMfINuPAnbZB8JdaRaq/0GTiZbFc9QcMd uO+UMNBWnJWbXdHU1d6MZiLt3g0IYq+ChB3J4a3w7smZmAT+gyQspJfYvZzPssXks0SnCvhB Jfk5o8toVDCmFnfCuD249rJk+OHZKHyRmVPqiVPi9ZbEQFnxke+8n566wr8Pkm/wV4ABAENX 89oNCmVuZHN0cmVhbQ1lbmRvYmoNMjUgMCBvYmo8PC9MZW5ndGggNDg0L0ZpbHRlci9GbGF0 ZURlY29kZT4+c3RyZWFtDQpIiXRTy46cMBC88xV9tCMtAgzzUK6ZQ/a63KIcGHAmKKyNDGSU 39gvTrnbM9nRKhfshurq6q6mfc7aT1mRF0V5oLbPnuK1MNRes29q1XVeqZ/6qcRh6etJ7/Oj Op3eFlz2ilynD3mjXhHhu65wp879QdZBAZ3gusSTXhCUibFzg2SGITHNnLPx8yz1JoaO/Oy7 9V3kHVlO/52UOal4kxsDnwgZcOEg9UFCImB61aWJilh8Ui4AJ/BedGyDlExKhT5ojKtRj9pS R4L4oZuY9DBIAS4YC2A9s3oniDDqssB53m6cHHr3WdTq7+1zVhBoytrsqf0izpnoHBtXiXEY MBIM3Fi1iWXkYAF7OKl3Suyp2Z5avS20sIteIBPjYamK2GHkcOmDXfURN4nhg4QpKUJnGzDS 6o5J9X0SYMPyMSfYmdVinCVP1iiRvwmmtyRkTpq64jiyz0b5pJT8P4pH9IxVU+G/cwhWGt/e Ny6wRHP5OK4HI453I+L4+7sl0YiXlXd9B73YdR7Qdp7g+U6NWOrRu5xafDZRU4WFsdiIiPY6 rqVbw3jeuFiJZoqmpiIWk7+0uVVLrq8+UDctWLk6jtfw7wg2LLGOa/TL+etkh4td0msnoIG6 vrfzKpnojf4KMABhR/QKDQplbmRzdHJlYW0NZW5kb2JqDTI2IDAgb2JqPDwvVHlwZS9Gb250 L0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9CYXNlRm9udC9UaW1lc05ld1JvbWFuUFMtSXRh bGljTVQvRmlyc3RDaGFyIDMyL0xhc3RDaGFyIDExOC9TdWJ0eXBlL1RydWVUeXBlL0ZvbnRE ZXNjcmlwdG9yIDMwIDAgUi9XaWR0aHNbMjUwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA3MjIgNjExIDAg MCAwIDMzMyAwIDAgMCAwIDAgMCA2MTEgMCAwIDUwMCAwIDcyMiAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgNTAwIDAgMCA1MDAgNDQ0IDAgNTAwIDAgMjc4IDAgMCAyNzggNzIyIDUwMCA1MDAg NTAwIDAgMzg5IDM4OSAyNzggNTAwIDQ0NF0+Pg1lbmRvYmoNMjcgMCBvYmo8PC9MZW5ndGgg NTQ5L0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiXxTTY+bMBC98yvmaEtlYoO/qHrp tjl0TyuF22oPLGET2i5EQBTl33fGTtJUrXrBBp7fzHvzXD9musSqMqCg/prlCpVSDuo2exbL vlmkxyDg23q9lhatgKAKLDRIJ96bM8icVqkVYRqpUIsfHSz7fgb5Uj9meRGwYOpcozaVvxUo mJ83pYX6RJXaUeZWDPxYpEMjJpkbLEVPpEa8HuOPPoHgcHzlzc++xVRnXWfGYYDCWSwcWB1Q kR40vqoCTF32lj3UmS5IogJaLEkA7S16ozTU77EVVcWmuB/x1CzdsICsv9MHbt5y67+tEU8j VT9HAIlXF+a407pCDzqU6FRij5K1vmqmDqPmes8ateigHYe0XaQm0VPPguP7OAGb6cRbE21m R+iPJ/HNBKd+uXDEATHukN4bmbNxpOKe+A4wpoVVfIBmhnkhydsLWT8kX1dfZgftnMTB3A5Z YdFpF1JWoizDsqJCWyVdm65dZEmJ6ONzlIY6GcDB+EYRInoOTUJQ9xodORDz5QmXb2j8XnyO oE1CNTLQsWGb1imSbNPJOeIeJFnOkvhTcwHcolF6h2WgiRScCu15+GTOXTD+PUECsrqUjsLf 0vEsXs9UgmYQCzXUoxGn+VruelqhpUQGLv3/aobSGu7LwS5Za2PU4BOn7O9R0J1T4Y9ba9Kt 3S/L4eNqRRNlyxwHajtj33UdjtNutTv229irJreM84kBfgkwABPW6l8NCmVuZHN0cmVhbQ1l bmRvYmoNMjggMCBvYmo8PC9MZW5ndGggNDUwL0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFt DQpIiVRSsW7bMBDd9RUHdCEHnUiKpKgOGZJ4SKcCZSejg2LRjgNbdkWlQf++R9JuYhiyjrq7 994d35qF2HDHnnndomZ/D8N7bGLYLLbu8GWhzPHwxfJf/lu18pU0FqUD2Qk0DpR06SVQO5hD ta3uqUKgUCDoV6K209hZ6lAoNfhjJWBHj99UlBbSgH+v1uwOhmmEPXckYSIlDDJj4z21gt9W LRple0L1j6XRJog6hUIWjJ8T12jZGOa4cCnYcDnvecJM4S7/w/dhoU+ByFo2pRCeYuQdGvbG a0kKQjkBt+zxbd4nsOnSm2XVymHvFFCx1H131UTTXjXprmh6Wq1W8GOh4YZ5jMBrQgx/woG4 LTudj4Fb7JOIy7S6TCsl9rS0Mm3eVYIjdv9aNQ/RwiaWFUPcTMStDC0yV5eN5OWs2cuynL82 Tcz8xCQZicB9CAFPc6bsUbjefay1jLBmuyYrfD4NWeA8Nudhabbl9JvXCh3D87i9+kJphUqB NARIN2aLKdLV/PfFxRQKNBkj1VqBVqXL++SJMiIBaotks15h58CQzYS+RaS8oAJDBWBdwrtJ S9kmZ5a8NpKYbgvgnwADAFDQrcENCmVuZHN0cmVhbQ1lbmRvYmoNMjkgMCBvYmo8PC9MZW5n dGggMjU3NS9GaWx0ZXIvRmxhdGVEZWNvZGUvTiAzL0FsdGVybmF0ZS9EZXZpY2VSR0I+PnN0 cmVhbQ0KSImclnlUU3cWx39vyZ6QlbDDYw1bgLAGkDVsYZEdBFEISQgBEkJI2AVBRAUURUSE qpUy1m10Rk9FnS6uY60O1n3q0gP1MOroOLQW146dFzhHnU5nptPvH+/3Ofd37+/d3733nfMA oCelqrXVMAsAjdagz0qMxRYVFGKkCQADCiACEQAyea0uLTshB+CSxkuwWtwJ/IueXgeQab0i TMrAMPD/iS3X6Q0AQBk4ByiUtXKcO3GuqjfoTPYZnHmllSaGURPr8QRxtjSxap6953zmOdrE Co1WgbMpZ51CozDxaZxX1xmVOCOpOHfVqZX1OF/F2aXKqFHj/NwUq1HKagFA6Sa7QSkvx9kP Z7o+J0uC8wIAyHTVO1z6DhuUDQbTpSTVuka9WlVuwNzlHpgoNFSMJSnrq5QGgzBDJq+U6RWY pFqjk2kbAZi/85w4ptpieJGDRaHBwUJ/H9E7hfqvm79Qpt7O05PMuZ5B/AtvbT/nVz0KgHgW r836t7bSLQCMrwTA8uZbm8v7ADDxvh2++M59+KZ5KTcYdGG+vvX19T5qpdzHVNA3+p8Ov0Dv vM/HdNyb8mBxyjKZscqAmeomr66qNuqxWp1MrsSEPx3iXx3483l4ZynLlHqlFo/Iw6dMrVXh 7dYq1AZ1tRZTa/9TE39l2E80P9e4uGOvAa/YB7Au8gDytwsA5dIAUrQN34He9C2Vkgcy8DXf 4d783M8J+vdT4T7To1atmouTZOVgcqO+bn7P9FkCAqACJuABK2APnIE7EAJ/EALCQTSIB8kg HeSAArAUyEE50AA9qActoB10gR6wHmwCw2A7GAO7wX5wEIyDj8EJ8EdwHnwJroFbYBJMg4dg BjwFryAIIkEMiAtZQQ6QK+QF+UNiKBKKh1KhLKgAKoFUkBYyQi3QCqgH6oeGoR3Qbuj30FHo BHQOugR9BU1BD6DvoJcwAtNhHmwHu8G+sBiOgVPgHHgJrIJr4Ca4E14HD8Gj8D74MHwCPg9f gyfhh/AsAhAawkccESEiRiRIOlKIlCF6pBXpRgaRUWQ/cgw5i1xBJpFHyAuUiHJRDBWi4WgS movK0Rq0Fe1Fh9Fd6GH0NHoFnUJn0NcEBsGW4EUII0gJiwgqQj2hizBI2En4iHCGcI0wTXhK JBL5RAExhJhELCBWEJuJvcStxAPE48RLxLvEWRKJZEXyIkWQ0kkykoHURdpC2kf6jHSZNE16 TqaRHcj+5ARyIVlL7iAPkveQPyVfJt8jv6KwKK6UMEo6RUFppPRRxijHKBcp05RXVDZVQI2g 5lArqO3UIep+6hnqbeoTGo3mRAulZdLUtOW0IdrvaJ/Tpmgv6By6J11CL6Ib6evoH9KP07+i P2EwGG6MaEYhw8BYx9jNOMX4mvHcjGvmYyY1U5i1mY2YHTa7bPaYSWG6MmOYS5lNzEHmIeZF 5iMWheXGkrBkrFbWCOso6wZrls1li9jpbA27l72HfY59n0PiuHHiOQpOJ+cDzinOXS7CdeZK uHLuCu4Y9wx3mkfkCXhSXgWvh/db3gRvxpxjHmieZ95gPmL+ifkkH+G78aX8Kn4f/yD/Ov+l hZ1FjIXSYo3FfovLFs8sbSyjLZWW3ZYHLK9ZvrTCrOKtKq02WI1b3bFGrT2tM63rrbdZn7F+ ZMOzCbeR23TbHLS5aQvbetpm2TbbfmB7wXbWzt4u0U5nt8XulN0je759tH2F/YD9p/YPHLgO kQ5qhwGHzxz+ipljMVgVNoSdxmYcbR2THI2OOxwnHF85CZxynTqcDjjdcaY6i53LnAecTzrP uDi4pLm0uOx1uelKcRW7lrtudj3r+sxN4Jbvtspt3O2+wFIgFTQJ9gpuuzPco9xr3Efdr3oQ PcQelR5bPb70hD2DPMs9RzwvesFewV5qr61el7wJ3qHeWu9R7xtCujBGWCfcK5zy4fuk+nT4 jPs89nXxLfTd4HvW97VfkF+V35jfLRFHlCzqEB0Tfefv6S/3H/G/GsAISAhoCzgS8G2gV6Ay cFvgn4O4QWlBq4JOBv0jOCRYH7w/+EGIS0hJyHshN8Q8cYa4V/x5KCE0NrQt9OPQF2HBYYaw g2F/DxeGV4bvCb+/QLBAuWBswd0IpwhZxI6IyUgssiTy/cjJKMcoWdRo1DfRztGK6J3R92I8 Yipi9sU8jvWL1cd+FPtMEiZZJjkeh8QlxnXHTcRz4nPjh+O/TnBKUCXsTZhJDEpsTjyeREhK SdqQdENqJ5VLd0tnkkOSlyWfTqGnZKcMp3yT6pmqTz2WBqclp21Mu73QdaF24Xg6SJemb0y/ kyHIqMn4QyYxMyNzJPMvWaKslqyz2dzs4uw92U9zYnP6cm7luucac0/mMfOK8nbnPcuPy+/P n1zku2jZovMF1gXqgiOFpMK8wp2Fs4vjF29aPF0UVNRVdH2JYEnDknNLrZdWLf2kmFksKz5U QijJL9lT8oMsXTYqmy2Vlr5XOiOXyDfLHyqiFQOKB8oIZb/yXllEWX/ZfVWEaqPqQXlU+WD5 I7VEPaz+tiKpYnvFs8r0yg8rf6zKrzqgIWtKNEe1HG2l9nS1fXVD9SWdl65LN1kTVrOpZkaf ot9ZC9UuqT1i4OE/UxeM7saVxqm6yLqRuuf1efWHGtgN2oYLjZ6NaxrvNSU0/aYZbZY3n2xx bGlvmVoWs2xHK9Ra2nqyzbmts216eeLyXe3U9sr2P3X4dfR3fL8if8WxTrvO5Z13Vyau3Ntl 1qXvurEqfNX21ehq9eqJNQFrtqx53a3o/qLHr2ew54deee8Xa0Vrh9b+uK5s3URfcN+29cT1 2vXXN0Rt2NXP7m/qv7sxbePhAWyge+D7TcWbzg0GDm7fTN1s3Dw5lPpPAKQBW/6YuJkkmZCZ /JpomtWbQpuvnByciZz3nWSd0p5Anq6fHZ+Ln/qgaaDYoUehtqImopajBqN2o+akVqTHpTil qaYapoum/adup+CoUqjEqTepqaocqo+rAqt1q+msXKzQrUStuK4trqGvFq+LsACwdbDqsWCx 1rJLssKzOLOutCW0nLUTtYq2AbZ5tvC3aLfguFm40blKucK6O7q1uy67p7whvJu9Fb2Pvgq+ hL7/v3q/9cBwwOzBZ8Hjwl/C28NYw9TEUcTOxUvFyMZGxsPHQce/yD3IvMk6ybnKOMq3yzbL tsw1zLXNNc21zjbOts83z7jQOdC60TzRvtI/0sHTRNPG1EnUy9VO1dHWVdbY11zX4Nhk2OjZ bNnx2nba+9uA3AXcit0Q3ZbeHN6i3ynfr+A24L3hROHM4lPi2+Nj4+vkc+T85YTmDeaW5x/n qegy6LzpRunQ6lvq5etw6/vshu0R7ZzuKO6070DvzPBY8OXxcvH/8ozzGfOn9DT0wvVQ9d72 bfb794r4Gfio+Tj5x/pX+uf7d/wH/Jj9Kf26/kv+3P9t//8CDAD3hPP7Cg0KZW5kc3RyZWFt DWVuZG9iag0zMCAwIG9iajw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udEJCb3hbLTQ5OCAt MzA3IDExMjAgMTAyM10vRm9udE5hbWUvVGltZXNOZXdSb21hblBTLUl0YWxpY01UL0ZsYWdz IDk4L1N0ZW1WIDcxLjc0MjAwNC9DYXBIZWlnaHQgNjU2L1hIZWlnaHQgMC9Bc2NlbnQgODkx L0Rlc2NlbnQgLTIxNi9JdGFsaWNBbmdsZSAtMTUvRm9udEZhbWlseShUaW1lcyBOZXcgUm9t YW4pL0ZvbnRTdHJldGNoL05vcm1hbC9Gb250V2VpZ2h0IDQwMD4+DWVuZG9iag0xIDAgb2Jq PDwvQ29udGVudHMgMyAwIFIvVHlwZS9QYWdlL1BhcmVudCA2IDAgUi9Sb3RhdGUgMC9NZWRp YUJveFswIDAgNjEyIDc5Ml0vQ3JvcEJveFswIDAgNjEyIDc5Ml0vUmVzb3VyY2VzIDIgMCBS Pj4NZW5kb2JqDTIgMCBvYmo8PC9Gb250PDwvVFQyIDE0IDAgUi9UVDQgMTUgMCBSPj4vUHJv Y1NldFsvUERGL1RleHRdL0V4dEdTdGF0ZTw8L0dTMSAxOSAwIFI+Pj4+DWVuZG9iag0zIDAg b2JqPDwvTGVuZ3RoIDEyNjQvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJhFbbcts2 EH3XV+wj2JEQgjdReXIcO447cZOp2GQ6TR9gChIRMYQKQlLdD+n3dnGRRMt2Op44MAjsnj17 drGvbuYMVv3oshq9qqoEGFTLEUsgxh/8bxbDNC5pmUH1fRTDCv9Vtf21HxGIqm+4nDDKcqiu wkb104sLdJB5B/5WZm/FNI7j1FkNq/3oD/JOq+9RSRl5DZ/lTkSTnM7IGm62G8PhK9nh3pqu 6Mr+fREVNCGyM6Kldbj2NYrQw5SM4W3DpR7D7fX1NZ5jBMo4oQmDL9EMb6kopinRa9mt4Ear 7QaiP6ufh1FNHKzMw4JokkzzmNzJuuGihRsa7Mi2ldy6Tkgf4ZWMIMpoUtCCfI9Se8BdQMj7 p0cvOrWWPGBPAvYCsX+WtTgLIDkG4IAit+cZsVsWcmH3J4elRV+p14ARMMZiMjdiyTsF73hd yw7B9tZ5RpaItiBu88LvcAuyIHon2pZGOS490CwAzSzJalIfYFbv4C7KaElu/ddP8/cfP53Q Bjbr54n9LL/xB7gSO675hiNTNtnoNCP2A3WrxenrBf8HvYpOGP/pKYXPICs8suIc2Qs8To/a ZIFGaVqBdnIUJ8y3mw26nhKlDVjypk5TU6KDw1vv5U7dy1aaB+eNTeksxwIbyN+RMBfaWdg5 C5j8Hiq/w7v+5OZK9HLVQYVyyIlwWsoJ7JVe+2Am3v5Rwi9Flp7SEBBcCa7BSwO9pURZDSLx 4/9liR1ZCmL72MG9aHi7BLUE0wgn4EHxOZrYsPSCEzaj8ZCc5IRy5k3vBQa7bRfQyrUAo0B2 S6WRBgIP0cRKT23RJTfOb6DEWT2r6sTFcQAGH+7mb6HhPaywvXTANxutdry1HtwZGy8raTrz 6CZngTt5EB/hqyvNl5ipKY2h34haLqW7HVOU+SA4dgrOX6+5kaqzLucb1fVKO6+TpKRFMUzp GTOJZ+YSi0IZClUjtEBOxDhQHxVkwP4N9EarbtU+gOhqtdV8hVKzJ61cUVYZGWr2cfHmJ6+5 94qy3Xmx4lXspra6cifZoVq9UFNiY3MNfUr+3oiFNOJQEyUbMHPqEUlIuwOIxS9atfFlLjpj 1cU9wJLOhsI5UZsESRrtyqgItZqhBFGAIe73QShJQafsnOn0pHrUhFG1aulR/vbbM8UwzOoX Aa1Sa8CU7LleWAr4AkPHVKO+FrKvt32Pf/ReY1PKikMkJ897aZrHTQUTybsFyn+HLMKDVb3y egkmHkdxyhwLeuHGCDSACoDl1my1AJ8jIQyWZQ993YjFthULixzb08YIf+BeaGCFYwx7TenG BbdIc3w/MshQ6WXphoZjMn0UpnEhHieMNJ/Zk1mM/abwU4bj819ImD15Zr5M3elH5lnprvTm zHI5QxKGlp9regQS7PFjuJQruO1b5HMM7/meSzkOpZfRWfpsM7XcY63+onb4pk7QFT6kbwya MHwMv83f0Cdz0BkCFl6/T63gvYClwJFi6fjVfnwRrr3VCi3WBra99VDbozbXDT8UTpq/0FNc 5ZCdQJk8YIY1Sl3DX1vRGyc2tGYa2YMWK1QlPUrH2nMD2rPPx3Dku0RT8Ku73o9/+LgQO8cd JrjBQZY8UaWfrqKchAELx5UwNM1wZHLD1Q+eo9Oirl/D76pvZCO1go/NPXdj1KENokXZ+17r qurR/etq9N8ADl/SSQoNCmVuZHN0cmVhbQ1lbmRvYmoNNCAwIG9iajw8L051bXNbMCA1IDAg Ul0+Pg1lbmRvYmoNNSAwIG9iajw8L1MvRD4+DWVuZG9iag02IDAgb2JqPDwvQ291bnQgMi9L aWRzWzEyIDAgUiAxIDAgUl0vVHlwZS9QYWdlcz4+DWVuZG9iag03IDAgb2JqPDwvTGVuZ3Ro IDMzODkvVHlwZS9NZXRhZGF0YS9TdWJ0eXBlL1hNTD4+c3RyZWFtDQo8P3hwYWNrZXQgYmVn aW49J++7vycgaWQ9J1c1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCc/Pgo8P2Fkb2JlLXhhcC1m aWx0ZXJzIGVzYz0iQ1JMRiI/Pg0KPHg6eG1wbWV0YSB4bWxuczp4PSdhZG9iZTpuczptZXRh LycgeDp4bXB0az0nWE1QIHRvb2xraXQgMi45LjEtMTMsIGZyYW1ld29yayAxLjYnPg0KPHJk ZjpSREYgeG1sbnM6cmRmPSdodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50 YXgtbnMjJyB4bWxuczppWD0naHR0cDovL25zLmFkb2JlLmNvbS9pWC8xLjAvJz4NCjxyZGY6 RGVzY3JpcHRpb24gcmRmOmFib3V0PSd1dWlkOjlkMTI0OWVjLWNkMGItNDllYS05NDc0LTcw ODU0ZjA5MzQ5OScgeG1sbnM6cGRmPSdodHRwOi8vbnMuYWRvYmUuY29tL3BkZi8xLjMvJyBw ZGY6UHJvZHVjZXI9J0Fjcm9iYXQgRGlzdGlsbGVyIDYuMC4xIChXaW5kb3dzKSc+PC9yZGY6 RGVzY3JpcHRpb24+DQo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0ndXVpZDo5ZDEyNDll Yy1jZDBiLTQ5ZWEtOTQ3NC03MDg1NGYwOTM0OTknIHhtbG5zOnhhcD0naHR0cDovL25zLmFk b2JlLmNvbS94YXAvMS4wLycgeGFwOkNyZWF0ZURhdGU9JzIwMDctMDctMjJUMDc6NTI6NTAt MDc6MDAnIHhhcDpDcmVhdG9yVG9vbD0nUFNjcmlwdDUuZGxsIFZlcnNpb24gNS4yLjInIHhh cDpNb2RpZnlEYXRlPScyMDA3LTA3LTIyVDA3OjUyOjUwLTA3OjAwJz48L3JkZjpEZXNjcmlw dGlvbj4NCjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSd1dWlkOjlkMTI0OWVjLWNkMGIt NDllYS05NDc0LTcwODU0ZjA5MzQ5OScgeG1sbnM6eGFwTU09J2h0dHA6Ly9ucy5hZG9iZS5j b20veGFwLzEuMC9tbS8nIHhhcE1NOkRvY3VtZW50SUQ9J3V1aWQ6Y2VkMTFlM2UtZmFkMC00 NmY1LWExNzAtY2QwMTM2ZDJhYjlkJy8+DQo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0n dXVpZDo5ZDEyNDllYy1jZDBiLTQ5ZWEtOTQ3NC03MDg1NGYwOTM0OTknIHhtbG5zOmRjPSdo dHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLycgZGM6Zm9ybWF0PSdhcHBsaWNhdGlv bi9wZGYnPjxkYzp0aXRsZT48cmRmOkFsdD48cmRmOmxpIHhtbDpsYW5nPSd4LWRlZmF1bHQn Pk1pY3Jvc29mdCBXb3JkIC0gMjEtMDctMDI4Ni0wMC0wMDAwLUxpYWlzb24tdG8tSUVURi1N SVBTSE9QLWZyb20tODAyLTIxLUp1bC0yMDA3LmRvYzwvcmRmOmxpPjwvcmRmOkFsdD48L2Rj OnRpdGxlPjxkYzpjcmVhdG9yPjxyZGY6U2VxPjxyZGY6bGk+VkdVUFRBMjwvcmRmOmxpPjwv cmRmOlNlcT48L2RjOmNyZWF0b3I+PC9yZGY6RGVzY3JpcHRpb24+DQo8L3JkZjpSREY+DQo8 L3g6eG1wbWV0YT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAKPD94cGFja2V0IGVuZD0ndyc/Pg0KZW5kc3RyZWFtDWVuZG9iag04IDAgb2Jq PDwvTW9kRGF0ZShEOjIwMDcwNzIyMDc1MjUwLTA3JzAwJykvQ3JlYXRpb25EYXRlKEQ6MjAw NzA3MjIwNzUyNTAtMDcnMDAnKS9UaXRsZShNaWNyb3NvZnQgV29yZCAtIDIxLTA3LTAyODYt MDAtMDAwMC1MaWFpc29uLXRvLUlFVEYtTUlQU0hPUC1mcm9tLTgwMi0yMS1KdWwtMjAwNy5k b2MpL0NyZWF0b3IoUFNjcmlwdDUuZGxsIFZlcnNpb24gNS4yLjIpL1Byb2R1Y2VyKEFjcm9i YXQgRGlzdGlsbGVyIDYuMC4xIFwoV2luZG93c1wpKS9BdXRob3IoVkdVUFRBMik+Pg1lbmRv YmoNeHJlZg0KMCA5DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMTA4NDcgMDAwMDAgbg0K MDAwMDAxMDk3MiAwMDAwMCBuDQowMDAwMDExMDY2IDAwMDAwIG4NCjAwMDAwMTIzOTkgMDAw MDAgbg0KMDAwMDAxMjQzMiAwMDAwMCBuDQowMDAwMDEyNDU1IDAwMDAwIG4NCjAwMDAwMTI1 MTIgMDAwMDAgbg0KMDAwMDAxNTk3NyAwMDAwMCBuDQp0cmFpbGVyDQo8PC9TaXplIDk+Pg0K c3RhcnR4cmVmDQoxMTYNCiUlRU9GDQo= --------------030509030206060902020208 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --------------030509030206060902020208-- From dime-bounces@ietf.org Mon Mar 3 02:55:15 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4166E28C547; Mon, 3 Mar 2008 02:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.143 X-Spam-Level: X-Spam-Status: No, score=-0.143 tagged_above=-999 required=5 tests=[AWL=-0.306, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_111=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPzSh3cGeV2T; Mon, 3 Mar 2008 02:55:14 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DE683A6E8E; Mon, 3 Mar 2008 02:55:09 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82C1D28C4F6 for ; Mon, 3 Mar 2008 02:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4C27JMsFe1ne for ; Mon, 3 Mar 2008 02:55:07 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id E05133A67AC for ; Mon, 3 Mar 2008 02:54:31 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 9522B19884E; Mon, 3 Mar 2008 12:54:22 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 52E89198727; Mon, 3 Mar 2008 12:54:22 +0200 (EET) Message-ID: <47CBD8E0.2080207@piuha.net> Date: Mon, 03 Mar 2008 12:54:24 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: draft-ietf-dime-rfc3588bis@tools.ietf.org References: <47C80F25.5070709@piuha.net> In-Reply-To: <47C80F25.5070709@piuha.net> X-Virus-Scanned: ClamAV using ClamSMTP Cc: dime@ietf.org Subject: [Dime] More minor comments on the rfc3588bis draft X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org > > Example-Request ::= < Diameter Header: 9999999, REQ, PXY > > { User-Name } > * { Origin-Host } > * [ AVP Something seems to be missing from the end. Add "]". > The authorization server (chain) directs the selection of proper Suggest rewriting "(chain)" as "(and the related chain of proxies)". > T(Potentially re-transmitted message) We had a lengthy discussion back at the time of the RFC3588 specification on the T flag. Based on real-world experience and implementations, do we still believe we need this flag? I apologize if this has already been discussed in Dime. Jari _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Mar 3 05:47:09 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A38B03A6C94; Mon, 3 Mar 2008 05:47:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.211 X-Spam-Level: X-Spam-Status: No, score=0.211 tagged_above=-999 required=5 tests=[AWL=-0.351, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qU8+Qj7n85sG; Mon, 3 Mar 2008 05:47:04 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1856D3A6A17; Mon, 3 Mar 2008 05:47:04 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0175F3A6D94 for ; Mon, 3 Mar 2008 05:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNRXqXshTVZi for ; Mon, 3 Mar 2008 05:46:57 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 3F79B3A6CD3 for ; Mon, 3 Mar 2008 05:46:57 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 45C3720DAB for ; Mon, 3 Mar 2008 14:46:14 +0100 (CET) X-AuditID: c1b4fb3c-ae0bbbb000007e19-3b-47cc0126e655 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2B84720D94 for ; Mon, 3 Mar 2008 14:46:14 +0100 (CET) Received: from eesmdmw020.eemea.ericsson.se ([159.107.3.34]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Mar 2008 14:46:13 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 3 Mar 2008 14:46:04 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Question on the use of the M-bit Thread-Index: Ach9NOy9LGbvFqr9S9CnPBXyKmn7Rg== From: "German Blanco" To: X-OriginalArrivalTime: 03 Mar 2008 13:46:13.0885 (UTC) FILETIME=[F269CAD0:01C87D34] X-Brightmail-Tracker: AAAAAA== Subject: [Dime] Question on the use of the M-bit X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0940725381==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0940725381== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C87D34.ED6DE876" This is a multi-part message in MIME format. ------_=_NextPart_001_01C87D34.ED6DE876 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, I have a very simple question on the M-bit, please help. My view is that the application may set this bit for an AVP in any instance of any request independently. That is, the M-bit is set when the peer is required to understand the AVP, with no other condition.=20 For example, I have this AVP for nationality of people that I use only for foreigners. In the authentication request of this application I send the nationality AVP with the M-bit set if the person is a foreigner since the Diameter application in the other peer needs to do something special, but if the person is local then I send the nationality AVP with the M-bit not set, since the default functionality will work. I also think that since the following restrictions are not explicit anywhere that I am aware, and they do not seem to serve any practical purpose, they should be avoided if possible. There are other people that think that the M-bit value is required to be the same in every instance of request of an specific type for one application. That is, they think that if the AVP has the M-bit set in the authentication request of an application, then it must have the same M-bit value every time this authentication request is sent. And there are yet other people that think that the value must be the same for every request of every type for one application. I haven't met anyone that thinks that the value needs to be the same for the AVP in all applications, but maybe I haven't search enough :-) Please help me by telling me if I am wrong and why or if you think that there are other reasons to support my view. By the way, maybe this is worth a clarification in RFC3588bis. Thanks, German Blanco.=20 ------_=_NextPart_001_01C87D34.ED6DE876 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [Dime] Question on the use of the M-bit

Hello all,

I have a very simple question on the = M-bit, please help.

My view is that the application may set = this bit for an AVP in any instance of any request independently. That = is, the M-bit is set when the peer is required to understand the AVP, = with no other condition.

For example, I have this AVP for = nationality of people that I use only for foreigners. In the = authentication request of this application I send the nationality AVP = with the M-bit set if the person is a foreigner since the Diameter = application in the other peer needs to do something special, but if the = person is local then I send the nationality AVP with the M-bit not set, = since the default functionality will work. I also think that since the = following restrictions are not explicit anywhere that I am aware, and = they do not seem to serve any practical purpose, they should be avoided = if possible.

There are other people that think that = the M-bit value is required to be the same in every instance of request = of an specific type for one application. That is, they think that if the = AVP has the M-bit set in the authentication request of an application, = then it must have the same M-bit value every time this authentication = request is sent.

And there are yet other people that = think that the value must be the same for every request of every type = for one application.

I haven't met anyone that thinks that = the value needs to be the same for the AVP in all applications, but = maybe I haven't search enough :-)

Please help me by telling me if I am = wrong and why or if you think that there are other reasons to support my = view.

By the way, maybe this is worth a = clarification in RFC3588bis.

Thanks,

German Blanco.

------_=_NextPart_001_01C87D34.ED6DE876-- --===============0940725381== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0940725381==-- From dime-bounces@ietf.org Mon Mar 3 06:11:00 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B0D928C20E; Mon, 3 Mar 2008 06:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.569 X-Spam-Level: X-Spam-Status: No, score=-0.569 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YAUc+5t59bM; Mon, 3 Mar 2008 06:10:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A49228C128; Mon, 3 Mar 2008 06:10:55 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5246A3A683F for ; Mon, 3 Mar 2008 06:10:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpWO4fQFL0xU for ; Mon, 3 Mar 2008 06:10:48 -0800 (PST) Received: from smtp103.rog.mail.re2.yahoo.com (smtp103.rog.mail.re2.yahoo.com [206.190.36.81]) by core3.amsl.com (Postfix) with SMTP id 4F5D728C580 for ; Mon, 3 Mar 2008 06:10:47 -0800 (PST) Received: (qmail 88244 invoked from network); 3 Mar 2008 14:10:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=NSG3T68UXc/gMPvS6atSMuLR356wDV+JonBKHY7I1EgXoX/skMmdsuBOTvAHcFKcR6UW1Qa4sxQ3PENo3XpjcosIIwP7SMQddl3iyhgUy7TnRuoA8moD6Y1tZmH5a9CEAuT0J4WyJVF3KrAk8u4+H0eTcQBR4jX/Z9lbtNp7zr0= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@rogers.com@72.140.46.24 with plain) by smtp103.rog.mail.re2.yahoo.com with SMTP; 3 Mar 2008 14:10:38 -0000 X-YMail-OSG: wWVWq8IVM1lqBTbg_npSS7q7bbuRJq5mD1wO40nGlX2vKpuy8KZnmXBjIyxrow.5IQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <47CC06DE.8090602@rogers.com> Date: Mon, 03 Mar 2008 09:10:38 -0500 From: Tom Taylor User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: German Blanco References: In-Reply-To: Cc: dime@ietf.org Subject: Re: [Dime] Question on the use of the M-bit X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org For what it's worth, I understood the M-bit from your point of view when I first worked with DIAMETER back in 1998. But I haven't been in close contact with implementation in the industry since then. German Blanco wrote: > Hello all, > > I have a very simple question on the M-bit, please help. > > My view is that the application may set this bit for an AVP in any > instance of any request independently. That is, the M-bit is set when > the peer is required to understand the AVP, with no other condition. > For example, I have this AVP for nationality of people that I use only > for foreigners. In the authentication request of this application I send > the nationality AVP with the M-bit set if the person is a foreigner > since the Diameter application in the other peer needs to do something > special, but if the person is local then I send the nationality AVP with > the M-bit not set, since the default functionality will work. I also > think that since the following restrictions are not explicit anywhere > that I am aware, and they do not seem to serve any practical purpose, > they should be avoided if possible. > > There are other people that think that the M-bit value is required to be > the same in every instance of request of an specific type for one > application. That is, they think that if the AVP has the M-bit set in > the authentication request of an application, then it must have the same > M-bit value every time this authentication request is sent. > > And there are yet other people that think that the value must be the > same for every request of every type for one application. > > I haven't met anyone that thinks that the value needs to be the same for > the AVP in all applications, but maybe I haven't search enough :-) > > Please help me by telling me if I am wrong and why or if you think that > there are other reasons to support my view. > > By the way, maybe this is worth a clarification in RFC3588bis. > > Thanks, > > German Blanco. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Mar 3 07:36:36 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 876713A6BB8; Mon, 3 Mar 2008 07:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CgcGFp9yBOi; Mon, 3 Mar 2008 07:36:35 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A6893A6D84; Mon, 3 Mar 2008 07:36:21 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EFC73A6CAE for ; Mon, 3 Mar 2008 07:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6iVJg5IZQgrm for ; Mon, 3 Mar 2008 07:36:16 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 2AFEA28C56F for ; Mon, 3 Mar 2008 07:35:09 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m23FYv8v014193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Mar 2008 16:34:57 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m23FYv7q003395; Mon, 3 Mar 2008 16:34:57 +0100 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Mar 2008 16:34:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 3 Mar 2008 16:34:57 +0100 Message-ID: <83C460304D3E5445B0388381DC69F2ED95933F@DEMUEXC013.nsn-intra.net> In-Reply-To: <47CC06DE.8090602@rogers.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Question on the use of the M-bit Thread-Index: Ach9OGUMBTRKUmi8T/m/yGj+u87qmwAC0WXw References: <47CC06DE.8090602@rogers.com> From: "Schendel, Jens (NSN - DE/Berlin)" To: "ext Tom Taylor" , "German Blanco" X-OriginalArrivalTime: 03 Mar 2008 15:34:57.0207 (UTC) FILETIME=[229DBC70:01C87D44] Cc: dime@ietf.org Subject: Re: [Dime] Question on the use of the M-bit X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, so far I haven't seen dynamic M-bit setting in specifications (hence also n= ot seen on interface implementations). Especially with respect to a Diamete= r server, I think that the application running on the server is basically e= xpected to handle incoming AVP according to local service policies. From th= is point of view it makes no real difference if M-Bit was set or not. The s= erver will use or ignore AVP according to service level agreement with the = network operator. Hence I feel that such dynamic handling is usually not ne= eded. May-be a point for Diameter design guidelines? This also comes to the question what "unrecognized" in 3588(bis) means in t= he context of M-Bit handling. The server may syntactically recognize any AV= P but may not or may not want to "recognize" it semantically... Also, the s= erver internal processing can hardly be seen on the interface (in the succe= ssful answer case). Thus I would additionally suggest adding a statement in 3588bis that for Di= ameter Server the AVP processing including M-bit evaluation depends on serv= er's local service policies. Jens = > -----Urspr=FCngliche Nachricht----- > Von: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] Im = > Auftrag von ext Tom Taylor > Gesendet: Montag, 3. M=E4rz 2008 15:11 > An: German Blanco > Cc: dime@ietf.org > Betreff: Re: [Dime] Question on the use of the M-bit > = > For what it's worth, I understood the M-bit from your point = > of view when I first = > worked with DIAMETER back in 1998. But I haven't been in = > close contact with = > implementation in the industry since then. > = > German Blanco wrote: > > Hello all, > > = > > I have a very simple question on the M-bit, please help. > > = > > My view is that the application may set this bit for an AVP in any > > instance of any request independently. That is, the M-bit = > is set when > > the peer is required to understand the AVP, with no other = > condition. = > > For example, I have this AVP for nationality of people that = > I use only > > for foreigners. In the authentication request of this = > application I send > > the nationality AVP with the M-bit set if the person is a foreigner > > since the Diameter application in the other peer needs to = > do something > > special, but if the person is local then I send the = > nationality AVP with > > the M-bit not set, since the default functionality will work. I also > > think that since the following restrictions are not = > explicit anywhere > > that I am aware, and they do not seem to serve any = > practical purpose, > > they should be avoided if possible. > > = > > There are other people that think that the M-bit value is = > required to be > > the same in every instance of request of an specific type for one > > application. That is, they think that if the AVP has the = > M-bit set in > > the authentication request of an application, then it must = > have the same > > M-bit value every time this authentication request is sent. > > = > > And there are yet other people that think that the value must be the > > same for every request of every type for one application. > > = > > I haven't met anyone that thinks that the value needs to be = > the same for > > the AVP in all applications, but maybe I haven't search enough :-) > > = > > Please help me by telling me if I am wrong and why or if = > you think that > > there are other reasons to support my view. > > = > > By the way, maybe this is worth a clarification in RFC3588bis. > > = > > Thanks, > > = > > German Blanco. = > > = > > = > > = > > = > -------------------------------------------------------------- > ---------- > > = > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > = _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Mar 3 07:54:25 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCDB728C2BD; Mon, 3 Mar 2008 07:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.104 X-Spam-Level: X-Spam-Status: No, score=0.104 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VMco+J+YiDq; Mon, 3 Mar 2008 07:54:25 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55FF628C0FD; Mon, 3 Mar 2008 07:54:19 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73B6A28C0E2 for ; Mon, 3 Mar 2008 07:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1lvU5jeT1kO for ; Mon, 3 Mar 2008 07:54:13 -0800 (PST) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.191]) by core3.amsl.com (Postfix) with ESMTP id DD21F3A69DE for ; Mon, 3 Mar 2008 07:53:43 -0800 (PST) Received: by rv-out-0910.google.com with SMTP id l15so56132rvb.49 for ; Mon, 03 Mar 2008 07:53:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; bh=eUY23ga4NxXNOMSbrCtNPMTZEFHJROhCgmGwm+IqmgQ=; b=Az/4M3tkg5ymfw1bNR02OECbNYPa79vH49JYkSvrePweOFxPN2njf4gJrfdnj//mDvftVVN4fWSLaWLBYjFt/E5Ooe4wOuOn51MxFBjTD3/9eaUIQKaBbXC0W9H6F1RFLoGiBomfMGOIRlHe7a7msEa8BKH7P42Y8LypEUpdOO4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=oDwBYhWnzztapB87a+wn36u5oN6RHw8j5aoP4DesWyy06Pgy8cYdPSTqErm20hdkOWn2Ppo5azq/ywb/wz9GdYdcVXpkpSnoDHn+SNDawkZri1yV+/Z3PbhxmoLzM985MuQITTAqh7oHDzvaaudrh5VNuqktfPsUR4M2DjxgL6A= Received: by 10.141.29.18 with SMTP id g18mr47057rvj.298.1204559613793; Mon, 03 Mar 2008 07:53:33 -0800 (PST) Received: by 10.141.50.5 with HTTP; Mon, 3 Mar 2008 07:53:33 -0800 (PST) Message-ID: <9cf5ced20803030753x6a7fcb7ck24ec607d666a46af@mail.gmail.com> Date: Mon, 3 Mar 2008 10:53:33 -0500 From: "David Frascone" To: dime@ietf.org MIME-Version: 1.0 X-Google-Sender-Auth: 93b201307c38c87f Subject: [Dime] WGLC for draft-ietf-dime-mip6-split X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2118186268==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============2118186268== Content-Type: multipart/alternative; boundary="----=_Part_13378_4848156.1204559613783" ------=_Part_13378_4848156.1204559613783 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline This is a Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-07.txt This is our 2nd WGLC on this document. There were many changes based on feedback received in the first WGLC, so we are having a second last call. Because of the timing of the impending IETF meeting and the interactions with other SDOs, we are setting the call for **4 weeks**. Please have your comments in no later than March 30. Please respond to this last call. If you have no complaints, an "it looks good" would still be helpful. Thanks! -Dave ------=_Part_13378_4848156.1204559613783 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline This is a Last Call for comments on
http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-07.txt

This is our 2nd WGLC on this document.  There were many changes based
on feedback received in the first WGLC, so we are having a second
last call.

Because of the timing of the impending IETF meeting and the interactions
with other SDOs, we are setting the call for **4 weeks**.

Please have your comments in no later than March 30.

Please respond to this last call.  If you have no complaints, an "it looks good"
would still be helpful.

Thanks!

-Dave
------=_Part_13378_4848156.1204559613783-- --===============2118186268== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============2118186268==-- From dime-bounces@ietf.org Mon Mar 3 08:01:10 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F4953A68C2; Mon, 3 Mar 2008 08:01:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.262 X-Spam-Level: X-Spam-Status: No, score=0.262 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2R9jWxUNQmi; Mon, 3 Mar 2008 08:01:08 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D55DA3A68F3; Mon, 3 Mar 2008 08:01:06 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 642373A68F3 for ; Mon, 3 Mar 2008 08:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8S-nqwkQeNE for ; Mon, 3 Mar 2008 08:00:59 -0800 (PST) Received: from sonussf2.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id A01D83A6B97 for ; Mon, 3 Mar 2008 08:00:42 -0800 (PST) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id m23G0WEI018172; Mon, 3 Mar 2008 11:00:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 3 Mar 2008 11:00:30 -0500 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7509868@sonusmail04.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Question on the use of the M-bit thread-index: Ach9NOy9LGbvFqr9S9CnPBXyKmn7RgACa5sQ References: From: "Asveren, Tolga" To: "German Blanco" , Subject: Re: [Dime] Question on the use of the M-bit X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2115624755==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============2115624755== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C87D47.B4939BC2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C87D47.B4939BC2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IMHO, what you need is an AVP indicated as optional in ABNF but with M-bit set. That it is optional in ABNF indicates that it may not be present. That it has M-bit set indicates that if present, it needs to be understood/processed. =20 M-bit value for an AVP can change for different commands. =20 Thanks, Tolga =20 ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of German Blanco Sent: Monday, March 03, 2008 8:46 AM To: dime@ietf.org Subject: [Dime] Question on the use of the M-bit =20 Hello all,=20 I have a very simple question on the M-bit, please help.=20 My view is that the application may set this bit for an AVP in any instance of any request independently. That is, the M-bit is set when the peer is required to understand the AVP, with no other condition.=20 For example, I have this AVP for nationality of people that I use only for foreigners. In the authentication request of this application I send the nationality AVP with the M-bit set if the person is a foreigner since the Diameter application in the other peer needs to do something special, but if the person is local then I send the nationality AVP with the M-bit not set, since the default functionality will work. I also think that since the following restrictions are not explicit anywhere that I am aware, and they do not seem to serve any practical purpose, they should be avoided if possible. There are other people that think that the M-bit value is required to be the same in every instance of request of an specific type for one application. That is, they think that if the AVP has the M-bit set in the authentication request of an application, then it must have the same M-bit value every time this authentication request is sent. And there are yet other people that think that the value must be the same for every request of every type for one application. I haven't met anyone that thinks that the value needs to be the same for the AVP in all applications, but maybe I haven't search enough :-) Please help me by telling me if I am wrong and why or if you think that there are other reasons to support my view.=20 By the way, maybe this is worth a clarification in RFC3588bis.=20 Thanks,=20 German Blanco.=20 ------_=_NextPart_001_01C87D47.B4939BC2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [Dime] Question on the use of the M-bit

IMHO, what you need is an AVP = indicated as optional in ABNF but with M-bit set. That it is optional in ABNF = indicates that it may not be present. That it has M-bit set indicates that if present, = it needs to be understood/processed.

 

M-bit value for an AVP can change = for different commands.

 

Thanks,

=

Tolga

 

From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of German Blanco
Sent: Monday, March 03, = 2008 8:46 AM
To: dime@ietf.org
Subject: [Dime] Question = on the use of the M-bit

 

Hello all,

I have a very simple question on the M-bit, please help. =

My view is that the application may set this bit for an AVP in any instance = of any request independently. That is, the M-bit is set when the peer is = required to understand the AVP, with no other condition. =

For example, I have this AVP for nationality of people that I use only for foreigners. In the authentication request of this application I send the nationality AVP with the M-bit set if the person is a foreigner since = the Diameter application in the other peer needs to do something special, = but if the person is local then I send the nationality AVP with the M-bit not = set, since the default functionality will work. I also think that since the following restrictions are not explicit anywhere that I am aware, and = they do not seem to serve any practical purpose, they should be avoided if = possible.

There are other people that think that the M-bit value is required to be the = same in every instance of request of an specific type for one application. That = is, they think that if the AVP has the M-bit set in the authentication = request of an application, then it must have the same M-bit value every time this authentication request is sent.

And there are yet other people that think that the value must be the same = for every request of every type for one application.

I haven't met anyone that thinks that the value needs to be the same for = the AVP in all applications, but maybe I haven't search enough = :-)

Please help me by telling me if I am wrong and why or if you think that there = are other reasons to support my view.

By the way, maybe this is worth a clarification in = RFC3588bis.

Thanks,

German Blanco.

------_=_NextPart_001_01C87D47.B4939BC2-- --===============2115624755== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============2115624755==-- From dime-bounces@ietf.org Mon Mar 3 08:14:15 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF69E3A6A68; Mon, 3 Mar 2008 08:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.477 X-Spam-Level: X-Spam-Status: No, score=-0.477 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GI6M6F7ml9xX; Mon, 3 Mar 2008 08:14:10 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1516B28C217; Mon, 3 Mar 2008 08:12:31 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FC243A6A25 for ; Mon, 3 Mar 2008 08:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcFqIYcXHhuk for ; Mon, 3 Mar 2008 08:12:24 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:20e:7fff:fe65:c513]) by core3.amsl.com (Postfix) with ESMTP id 254863A6AAF for ; Mon, 3 Mar 2008 08:12:19 -0800 (PST) Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id m23GBt1s064583; Mon, 3 Mar 2008 11:11:55 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <47CC233F.3080009@tari.toshiba.com> Date: Mon, 03 Mar 2008 11:11:43 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: "Schendel, Jens (NSN - DE/Berlin)" References: <47CC06DE.8090602@rogers.com> <83C460304D3E5445B0388381DC69F2ED95933F@DEMUEXC013.nsn-intra.net> In-Reply-To: <83C460304D3E5445B0388381DC69F2ED95933F@DEMUEXC013.nsn-intra.net> Cc: dime@ietf.org Subject: Re: [Dime] Question on the use of the M-bit X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, Comments inline. > Hi, > > so far I haven't seen dynamic M-bit setting in specifications (hence also= not seen on interface implementations). Especially with respect to a Diame= ter server, I think that the application running on the server is basically= expected to handle incoming AVP according to local service policies. From = this point of view it makes no real difference if M-Bit was set or not. = Typically, 'M' bit settings are design time (based on a app spec) rather = than run-time decisions. Also, based on the current base spec, it does = matter if the 'M' bit is set or not. See Sec 4.1. > The server will use or ignore AVP according to service level agreement wi= th the network operator. Hence I feel that such dynamic handling is usually= not needed. May-be a point for Diameter design guidelines? > = There's ongoing work with regards to extensibility that will likely = include clarifying/updating M-bit usage/scope etc. See previous threads = on 'Design Team on Diameter Extensibility'. > This also comes to the question what "unrecognized" in 3588(bis) means in= the context of M-Bit handling. The server may syntactically recognize any = AVP but may not or may not want to "recognize" it semantically... = "unrecognized" in the context of an M-bit means syntactically and = semantically understood but the receiving entity. Despite the fact that = you may not use it. Pls see Tolga's response for appropriate alternative. regards, victor > Also, the server internal processing can hardly be seen on the interface = (in the successful answer case). > Thus I would additionally suggest adding a statement in 3588bis that for = Diameter Server the AVP processing including M-bit evaluation depends on se= rver's local service policies. > = > Jens = > > = >> -----Urspr=FCngliche Nachricht----- >> Von: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] Im = >> Auftrag von ext Tom Taylor >> Gesendet: Montag, 3. M=E4rz 2008 15:11 >> An: German Blanco >> Cc: dime@ietf.org >> Betreff: Re: [Dime] Question on the use of the M-bit >> >> For what it's worth, I understood the M-bit from your point = >> of view when I first = >> worked with DIAMETER back in 1998. But I haven't been in = >> close contact with = >> implementation in the industry since then. >> >> German Blanco wrote: >> = >>> Hello all, >>> >>> I have a very simple question on the M-bit, please help. >>> >>> My view is that the application may set this bit for an AVP in any >>> instance of any request independently. That is, the M-bit = >>> = >> is set when >> = >>> the peer is required to understand the AVP, with no other = >>> = >> condition. = >> = >>> For example, I have this AVP for nationality of people that = >>> = >> I use only >> = >>> for foreigners. In the authentication request of this = >>> = >> application I send >> = >>> the nationality AVP with the M-bit set if the person is a foreigner >>> since the Diameter application in the other peer needs to = >>> = >> do something >> = >>> special, but if the person is local then I send the = >>> = >> nationality AVP with >> = >>> the M-bit not set, since the default functionality will work. I also >>> think that since the following restrictions are not = >>> = >> explicit anywhere >> = >>> that I am aware, and they do not seem to serve any = >>> = >> practical purpose, >> = >>> they should be avoided if possible. >>> >>> There are other people that think that the M-bit value is = >>> = >> required to be >> = >>> the same in every instance of request of an specific type for one >>> application. That is, they think that if the AVP has the = >>> = >> M-bit set in >> = >>> the authentication request of an application, then it must = >>> = >> have the same >> = >>> M-bit value every time this authentication request is sent. >>> >>> And there are yet other people that think that the value must be the >>> same for every request of every type for one application. >>> >>> I haven't met anyone that thinks that the value needs to be = >>> = >> the same for >> = >>> the AVP in all applications, but maybe I haven't search enough :-) >>> >>> Please help me by telling me if I am wrong and why or if = >>> = >> you think that >> = >>> there are other reasons to support my view. >>> >>> By the way, maybe this is worth a clarification in RFC3588bis. >>> >>> Thanks, >>> >>> German Blanco. = >>> >>> >>> >>> >>> = >> -------------------------------------------------------------- >> ---------- >> = >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> = >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> >> = > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > > > = _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Mar 3 08:18:38 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4B4B3A6C71; Mon, 3 Mar 2008 08:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.232 X-Spam-Level: X-Spam-Status: No, score=-0.232 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7+8LOeXsIl4; Mon, 3 Mar 2008 08:18:37 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D26293A68BF; Mon, 3 Mar 2008 08:18:28 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E40AB3A6BEB for ; Mon, 3 Mar 2008 08:18:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pa5wcXyssqB for ; Mon, 3 Mar 2008 08:18:25 -0800 (PST) Received: from sonussf2.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id C10703A6854 for ; Mon, 3 Mar 2008 08:17:27 -0800 (PST) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id m23GHEPA030459; Mon, 3 Mar 2008 11:17:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 3 Mar 2008 11:17:12 -0500 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7509869@sonusmail04.sonusnet.com> In-Reply-To: <83C460304D3E5445B0388381DC69F2ED95933F@DEMUEXC013.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Question on the use of the M-bit thread-index: Ach9OGUMBTRKUmi8T/m/yGj+u87qmwAC0WXwAAFGgcA= References: <47CC06DE.8090602@rogers.com> <83C460304D3E5445B0388381DC69F2ED95933F@DEMUEXC013.nsn-intra.net> From: "Asveren, Tolga" To: "Schendel, Jens (NSN - DE/Berlin)" , "ext Tom Taylor" , "German Blanco" Cc: dime@ietf.org Subject: Re: [Dime] Question on the use of the M-bit X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Jens, Please see below for comments. Thanks, Tolga > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > Schendel, Jens (NSN - DE/Berlin) > Sent: Monday, March 03, 2008 10:35 AM > To: ext Tom Taylor; German Blanco > Cc: dime@ietf.org > Subject: Re: [Dime] Question on the use of the M-bit > = > Hi, > = > so far I haven't seen dynamic M-bit setting in specifications (hence also > not seen on interface implementations). Especially with respect to a > Diameter server, I think that the application running on the server is > basically expected to handle incoming AVP according to local service > policies. From this point of view it makes no real difference if M-Bit was > set or not. The server will use or ignore AVP according to service level > agreement with the network operator. Hence I feel that such dynamic > handling is usually not needed. May-be a point for Diameter design > guidelines? [TOLGA]I agree with your comments about dynamic M-bit setting. M-bit indica= tes that processing the AVP is required for the semantics of the applicatio= n. I disagree about basing the decision to process AVPs on local policy dec= isions. If so, what would be the point to have M-bit at all? > This also comes to the question what "unrecognized" in 3588(bis) means in > the context of M-Bit handling. The server may syntactically recognize any > AVP but may not or may not want to "recognize" it semantically... Also, > the server internal processing can hardly be seen on the interface (in the > successful answer case). > Thus I would additionally suggest adding a statement in 3588bis that for > Diameter Server the AVP processing including M-bit evaluation depends on > server's local service policies. > = > Jens > = > > -----Urspr=FCngliche Nachricht----- > > Von: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] Im > > Auftrag von ext Tom Taylor > > Gesendet: Montag, 3. M=E4rz 2008 15:11 > > An: German Blanco > > Cc: dime@ietf.org > > Betreff: Re: [Dime] Question on the use of the M-bit > > > > For what it's worth, I understood the M-bit from your point > > of view when I first > > worked with DIAMETER back in 1998. But I haven't been in > > close contact with > > implementation in the industry since then. > > > > German Blanco wrote: > > > Hello all, > > > > > > I have a very simple question on the M-bit, please help. > > > > > > My view is that the application may set this bit for an AVP in any > > > instance of any request independently. That is, the M-bit > > is set when > > > the peer is required to understand the AVP, with no other > > condition. > > > For example, I have this AVP for nationality of people that > > I use only > > > for foreigners. In the authentication request of this > > application I send > > > the nationality AVP with the M-bit set if the person is a foreigner > > > since the Diameter application in the other peer needs to > > do something > > > special, but if the person is local then I send the > > nationality AVP with > > > the M-bit not set, since the default functionality will work. I also > > > think that since the following restrictions are not > > explicit anywhere > > > that I am aware, and they do not seem to serve any > > practical purpose, > > > they should be avoided if possible. > > > > > > There are other people that think that the M-bit value is > > required to be > > > the same in every instance of request of an specific type for one > > > application. That is, they think that if the AVP has the > > M-bit set in > > > the authentication request of an application, then it must > > have the same > > > M-bit value every time this authentication request is sent. > > > > > > And there are yet other people that think that the value must be the > > > same for every request of every type for one application. > > > > > > I haven't met anyone that thinks that the value needs to be > > the same for > > > the AVP in all applications, but maybe I haven't search enough :-) > > > > > > Please help me by telling me if I am wrong and why or if > > you think that > > > there are other reasons to support my view. > > > > > > By the way, maybe this is worth a clarification in RFC3588bis. > > > > > > Thanks, > > > > > > German Blanco. > > > > > > > > > > > > > > -------------------------------------------------------------- > > ---------- > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Mar 3 08:34:45 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 810A13A693D; Mon, 3 Mar 2008 08:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBn0D6XL5pou; Mon, 3 Mar 2008 08:34:44 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B60313A6AF5; Mon, 3 Mar 2008 08:34:08 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59C263A6A37 for ; Mon, 3 Mar 2008 08:34:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8PYeatAlFK4 for ; Mon, 3 Mar 2008 08:34:01 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id ADECE3A6B83 for ; Mon, 3 Mar 2008 08:33:11 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m23GWxq2001476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Mar 2008 17:32:59 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m23GWrFY006545; Mon, 3 Mar 2008 17:32:53 +0100 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Mar 2008 17:32:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 3 Mar 2008 17:32:53 +0100 Message-ID: <83C460304D3E5445B0388381DC69F2ED959341@DEMUEXC013.nsn-intra.net> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7509869@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Question on the use of the M-bit Thread-Index: Ach9OGUMBTRKUmi8T/m/yGj+u87qmwAC0WXwAAFGgcAAAJdeIA== References: <47CC06DE.8090602@rogers.com> <83C460304D3E5445B0388381DC69F2ED95933F@DEMUEXC013.nsn-intra.net> <033458F56EC2A64E8D2D7B759FA3E7E7509869@sonusmail04.sonusnet.com> From: "Schendel, Jens (NSN - DE/Berlin)" To: "ext Asveren, Tolga" , "ext Tom Taylor" , "German Blanco" , "ext Victor Fajardo" X-OriginalArrivalTime: 03 Mar 2008 16:32:53.0087 (UTC) FILETIME=[3A66EEF0:01C87D4C] Cc: dime@ietf.org Subject: Re: [Dime] Question on the use of the M-bit X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Tolga, Victor, = thanks for your responses. One comment inline. Jens > -----Urspr=FCngliche Nachricht----- > Von: ext Asveren, Tolga [mailto:tasveren@sonusnet.com] = > Gesendet: Montag, 3. M=E4rz 2008 17:17 > An: Schendel, Jens (NSN - DE/Berlin); ext Tom Taylor; German Blanco > Cc: dime@ietf.org > Betreff: RE: [Dime] Question on the use of the M-bit > = > Hi Jens, > = > Please see below for comments. > = > Thanks, > Tolga > = > > -----Original Message----- > > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] = > On Behalf Of > > Schendel, Jens (NSN - DE/Berlin) > > Sent: Monday, March 03, 2008 10:35 AM > > To: ext Tom Taylor; German Blanco > > Cc: dime@ietf.org > > Subject: Re: [Dime] Question on the use of the M-bit > > = > > Hi, > > = > > so far I haven't seen dynamic M-bit setting in = > specifications (hence also > > not seen on interface implementations). Especially with respect to a > > Diameter server, I think that the application running on = > the server is > > basically expected to handle incoming AVP according to local service > > policies. From this point of view it makes no real = > difference if M-Bit was > > set or not. The server will use or ignore AVP according to = > service level > > agreement with the network operator. Hence I feel that such dynamic > > handling is usually not needed. May-be a point for Diameter design > > guidelines? > [TOLGA]I agree with your comments about dynamic M-bit = > setting. M-bit indicates that processing the AVP is required = > for the semantics of the application. I disagree about basing = > the decision to process AVPs on local policy decisions. If = > so, what would be the point to have M-bit at all? [JS] Yes, actually at least for the limited scope of server processing I do= not see a need. > > This also comes to the question what "unrecognized" in = > 3588(bis) means in > > the context of M-Bit handling. The server may syntactically = > recognize any > > AVP but may not or may not want to "recognize" it = > semantically... Also, > > the server internal processing can hardly be seen on the = > interface (in the > > successful answer case). > > Thus I would additionally suggest adding a statement in = > 3588bis that for > > Diameter Server the AVP processing including M-bit = > evaluation depends on > > server's local service policies. > > = > > Jens > > = > > > -----Urspr=FCngliche Nachricht----- > > > Von: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] Im > > > Auftrag von ext Tom Taylor > > > Gesendet: Montag, 3. M=E4rz 2008 15:11 > > > An: German Blanco > > > Cc: dime@ietf.org > > > Betreff: Re: [Dime] Question on the use of the M-bit > > > > > > For what it's worth, I understood the M-bit from your point > > > of view when I first > > > worked with DIAMETER back in 1998. But I haven't been in > > > close contact with > > > implementation in the industry since then. > > > > > > German Blanco wrote: > > > > Hello all, > > > > > > > > I have a very simple question on the M-bit, please help. > > > > > > > > My view is that the application may set this bit for an = > AVP in any > > > > instance of any request independently. That is, the M-bit > > > is set when > > > > the peer is required to understand the AVP, with no other > > > condition. > > > > For example, I have this AVP for nationality of people that > > > I use only > > > > for foreigners. In the authentication request of this > > > application I send > > > > the nationality AVP with the M-bit set if the person is = > a foreigner > > > > since the Diameter application in the other peer needs to > > > do something > > > > special, but if the person is local then I send the > > > nationality AVP with > > > > the M-bit not set, since the default functionality will = > work. I also > > > > think that since the following restrictions are not > > > explicit anywhere > > > > that I am aware, and they do not seem to serve any > > > practical purpose, > > > > they should be avoided if possible. > > > > > > > > There are other people that think that the M-bit value is > > > required to be > > > > the same in every instance of request of an specific = > type for one > > > > application. That is, they think that if the AVP has the > > > M-bit set in > > > > the authentication request of an application, then it must > > > have the same > > > > M-bit value every time this authentication request is sent. > > > > > > > > And there are yet other people that think that the = > value must be the > > > > same for every request of every type for one application. > > > > > > > > I haven't met anyone that thinks that the value needs to be > > > the same for > > > > the AVP in all applications, but maybe I haven't search = > enough :-) > > > > > > > > Please help me by telling me if I am wrong and why or if > > > you think that > > > > there are other reasons to support my view. > > > > > > > > By the way, maybe this is worth a clarification in RFC3588bis. > > > > > > > > Thanks, > > > > > > > > German Blanco. > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > ---------- > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dime > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www.ietf.org/mailman/listinfo/dime > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > = _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Mar 3 09:55:05 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8989828C4AE; Mon, 3 Mar 2008 09:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTGOwYljB4kG; Mon, 3 Mar 2008 09:55:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 525D028C3D4; Mon, 3 Mar 2008 09:52:23 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59EB328C2BB for ; Mon, 3 Mar 2008 09:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPXr6Jgekknw for ; Mon, 3 Mar 2008 09:52:17 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 0067528C567 for ; Mon, 3 Mar 2008 09:50:30 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id D0F992C000357; Mon, 3 Mar 2008 18:50:21 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wJfogBRFRv2; Mon, 3 Mar 2008 18:50:21 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id B16A62C000355; Mon, 3 Mar 2008 18:50:11 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 3 Mar 2008 18:50:11 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF53E2FF@mx1.office> In-Reply-To: <47C99CC4.1080009@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Media Independent Handover &draft-stupar-dime-mos-options-00.txt Thread-Index: Ach7x/0H9KKnH09hSZ+Nt0ISnbYaBABjtcbQ References: <47C99CC4.1080009@gmx.net> From: "Patrick Stupar" To: "Hannes Tschofenig" , Subject: Re: [Dime] Media Independent Handover &draft-stupar-dime-mos-options-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Dear all, Please find some additional info about the MIH work that's currently being = done in MIPSHOP. Among this work's tasks, the one related to DIME WG is the= definition of a solution enabling the discovery of the functional elements= in the network providing the services defined by IEEE 802.21 - Media Indep= endent Handover (MIH) draft. Such services, named Mobility Services (MoS) o= r MIH services, are meant to enable efficient handover procedures among het= erogeneous technologies. To achieve this, IEEE 802.21 draft defines three t= ypes of services: - Information Service (IS), providing network topology information. = - Event Service (ES), indicating changes in state and transmission behavior= of the physical, data link and logical link layers of a device. - Command Service (CS), providing a way to control the physical, data link,= and logical link layers of a mobile terminal. The solution for the discovery of such services defines DNS and DHCP extens= ions to provide the IP address or the FQDN of the MIH Servers. The use of o= ne solution rather than the other depends on the location of the MIH server= (which can be in the home, visited or a third party network) and of the mo= bile node (home or visited network). = For further information, please see: Draft-ietf-mipshop-mstp-solution Draft-bajko-mos-dhcp-options Draft-bajko-mos-dns-discovery To complete the DHCP solution, Diameter AVP extensions are required. As alr= eady explained by Hannes, in this case MIH servers information (IP address = or FQDN) is transported from AAA server to the NAS, where it is transferred= to DHCP Relay (which in turn delivers it to the node). Draft-stupar-dime-m= os-options-00 defines such AVPs. The DHCP-based solution is quite similar to the one defined for MIPv6 boots= trapping for the integrated scenario. = Comments and reviews are welcome and appreciated Regards, Patrick -- Patrick Stupar Research Staff Member NEC Europe Ltd. NEC Laboratories Europe Network Division = Kurf=FCrsten-Anlage 36 = 69115 Heidelberg GERMANY = = phone +49 6221 4342 215 = fax +49 6221 4342 155 eMail: patrick.stupar@nw.neclab.eu NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014 = = > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On = > Behalf Of Hannes Tschofenig > Sent: Saturday, March 01, 2008 7:13 PM > To: dime@ietf.org > Subject: [Dime] Media Independent Handover = > &draft-stupar-dime-mos-options-00.txt > = > Folks, > = > I got some information from the IETF MIPSHOP chairs regarding = > a recently submitted draft: draft-stupar-dime-mos-options-00.txt > = > ---- > = > The MIPSHOP WG is working on a solution for a mobile node to = > discover 802.21 MIH servers when the mobile node attaches to = > an access router. Part of the solution involves delivering = > the MIH server information from a AAA server to the NAS on = > the access link. DHCP is then used to deliver the information = > to the mobile node. We need the DIME WG's help in completing = > the Diameter extensions for this. > = > The IEEE 802.21 WG is very interested in the MIH work we are = > doing in the IETF. They have sent a couple of liaison = > statements to the MIPSHOP WG saying they want this work = > completed in the IETF. I have attached one liaison letter we = > got from them recently. > = > --- > = > I told the MIPSHOP chairs that it would be nice to get a bit = > of information about the Media Independent Handover work so = > that DIME working group members are able to judge the = > specific solution. > = > Ciao > Hannes > = > = _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Mar 3 20:51:19 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D70F28C2D3; Mon, 3 Mar 2008 20:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.167 X-Spam-Level: ** X-Spam-Status: No, score=2.167 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIXlE+X8Zila; Mon, 3 Mar 2008 20:51:18 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 706BF3A6B2E; Mon, 3 Mar 2008 20:51:18 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E05FD3A6B2E; Mon, 3 Mar 2008 20:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6kOz7IX5YJi; Mon, 3 Mar 2008 20:51:11 -0800 (PST) Received: from jaguar.aricent.com (jaguar.aricent.com [61.246.186.17]) by core3.amsl.com (Postfix) with ESMTP id C36F43A687E; Mon, 3 Mar 2008 20:51:06 -0800 (PST) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id m244bgXQ017876; Tue, 4 Mar 2008 10:07:44 +0530 Received: from sandesh.gur.aricent.com (sandesh [10.203.142.21]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id m244bept017858; Tue, 4 Mar 2008 10:07:41 +0530 In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7509868@sonusmail04.sonusnet.com> To: "Asveren, Tolga" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Preeti Shandilya Date: Tue, 4 Mar 2008 10:20:33 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.5.5|November 30, 2005) at 04/03/2008 10:26:12 AM, Serialize complete at 04/03/2008 10:26:12 AM Cc: dime-bounces@ietf.org, dime@ietf.org Subject: Re: [Dime] Question on the use of the M-bit X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0082885396==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============0082885396== Content-Type: multipart/alternative; boundary="=_alternative 001A9A1365257402_=" This is a multipart message in MIME format. --=_alternative 001A9A1365257402_= Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIHlvdSBUb2xnYSwgIGJ1dCBSRkMgZG9lcyBub3QgbWVudGlvbiB0aGF0ICdB VlAgZmxhZyBydWxlIGZvciANCnRoZSBNIGJpdCBjYW4gbmV2ZXIgYmUgJ01BWScNCg0KU28gaWYg TSBiaXQgZm9yIGFueSBBVlAgaXMgbWVudGlvbmVkIGFzIE1BWSwgdGhpcyBpbmRpY2F0ZXMgdGhh dCBzZXJ2ZXIgDQptdXN0IHJlY29nbml6ZSB0aGlzIEFWUCwgaWYgTSBiaXQgaXMgc2V0LiBTZXJ2 ZXIgc2hvdWxkIG5vdCBnZW5lcmF0ZSBhbnkgDQplcnJvciBpZiBNIGJpdCBpcyBub3Qgc2V0IGZv ciB0aGUgc2FtZSBBVlANCg0KU28gdGhlb3JldGljYWxseSwgaXQgaXMgcG9zc2libGUgdGhhdCB0 aGVyZSBjYW4gYmUgYW4gQVZQIHdoaWNoIGNhbiBoYXZlIE0gDQpiaXQgc2V0IG9yIE0gYml0ICdu b3Qgc2V0Jy4gQWx0aG91Z2ggcHJhY3RpY2FsbHkgSSBkb24ndCBzZWUgYW55IHNjZW5hcmlvLg0K DQpyZWdhcmRzDQpQcmVldGkNCg0KDQoNCg0KIkFzdmVyZW4sIFRvbGdhIiA8dGFzdmVyZW5Ac29u dXNuZXQuY29tPiANClNlbnQgYnk6IGRpbWUtYm91bmNlc0BpZXRmLm9yZw0KMDMvMDMvMjAwOCAw OTozMCBQTQ0KDQoNClRvDQoiR2VybWFuIEJsYW5jbyIgPGdlcm1hbi5ibGFuY29AZXJpY3Nzb24u Y29tPiwgPGRpbWVAaWV0Zi5vcmc+DQpjYw0KDQpTdWJqZWN0DQpSZTogW0RpbWVdIFF1ZXN0aW9u IG9uIHRoZSB1c2Ugb2YgdGhlIE0tYml0DQoNCg0KDQoNCg0KDQpJTUhPLCB3aGF0IHlvdSBuZWVk IGlzIGFuIEFWUCBpbmRpY2F0ZWQgYXMgb3B0aW9uYWwgaW4gQUJORiBidXQgd2l0aCBNLWJpdCAN CnNldC4gVGhhdCBpdCBpcyBvcHRpb25hbCBpbiBBQk5GIGluZGljYXRlcyB0aGF0IGl0IG1heSBu b3QgYmUgcHJlc2VudC4gDQpUaGF0IGl0IGhhcyBNLWJpdCBzZXQgaW5kaWNhdGVzIHRoYXQgaWYg cHJlc2VudCwgaXQgbmVlZHMgdG8gYmUgDQp1bmRlcnN0b29kL3Byb2Nlc3NlZC4NCiANCk0tYml0 IHZhbHVlIGZvciBhbiBBVlAgY2FuIGNoYW5nZSBmb3IgZGlmZmVyZW50IGNvbW1hbmRzLg0KIA0K VGhhbmtzLA0KVG9sZ2ENCiANCg0KRnJvbTogZGltZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgDQpHZXJtYW4gQmxhbmNvDQpTZW50 OiBNb25kYXksIE1hcmNoIDAzLCAyMDA4IDg6NDYgQU0NClRvOiBkaW1lQGlldGYub3JnDQpTdWJq ZWN0OiBbRGltZV0gUXVlc3Rpb24gb24gdGhlIHVzZSBvZiB0aGUgTS1iaXQNCiANCkhlbGxvIGFs bCwgDQpJIGhhdmUgYSB2ZXJ5IHNpbXBsZSBxdWVzdGlvbiBvbiB0aGUgTS1iaXQsIHBsZWFzZSBo ZWxwLiANCk15IHZpZXcgaXMgdGhhdCB0aGUgYXBwbGljYXRpb24gbWF5IHNldCB0aGlzIGJpdCBm b3IgYW4gQVZQIGluIGFueSANCmluc3RhbmNlIG9mIGFueSByZXF1ZXN0IGluZGVwZW5kZW50bHku IFRoYXQgaXMsIHRoZSBNLWJpdCBpcyBzZXQgd2hlbiB0aGUgDQpwZWVyIGlzIHJlcXVpcmVkIHRv IHVuZGVyc3RhbmQgdGhlIEFWUCwgd2l0aCBubyBvdGhlciBjb25kaXRpb24uIA0KRm9yIGV4YW1w bGUsIEkgaGF2ZSB0aGlzIEFWUCBmb3IgbmF0aW9uYWxpdHkgb2YgcGVvcGxlIHRoYXQgSSB1c2Ug b25seSBmb3IgDQpmb3JlaWduZXJzLiBJbiB0aGUgYXV0aGVudGljYXRpb24gcmVxdWVzdCBvZiB0 aGlzIGFwcGxpY2F0aW9uIEkgc2VuZCB0aGUgDQpuYXRpb25hbGl0eSBBVlAgd2l0aCB0aGUgTS1i aXQgc2V0IGlmIHRoZSBwZXJzb24gaXMgYSBmb3JlaWduZXIgc2luY2UgdGhlIA0KRGlhbWV0ZXIg YXBwbGljYXRpb24gaW4gdGhlIG90aGVyIHBlZXIgbmVlZHMgdG8gZG8gc29tZXRoaW5nIHNwZWNp YWwsIGJ1dCANCmlmIHRoZSBwZXJzb24gaXMgbG9jYWwgdGhlbiBJIHNlbmQgdGhlIG5hdGlvbmFs aXR5IEFWUCB3aXRoIHRoZSBNLWJpdCBub3QgDQpzZXQsIHNpbmNlIHRoZSBkZWZhdWx0IGZ1bmN0 aW9uYWxpdHkgd2lsbCB3b3JrLiBJIGFsc28gdGhpbmsgdGhhdCBzaW5jZSANCnRoZSBmb2xsb3dp bmcgcmVzdHJpY3Rpb25zIGFyZSBub3QgZXhwbGljaXQgYW55d2hlcmUgdGhhdCBJIGFtIGF3YXJl LCBhbmQgDQp0aGV5IGRvIG5vdCBzZWVtIHRvIHNlcnZlIGFueSBwcmFjdGljYWwgcHVycG9zZSwg dGhleSBzaG91bGQgYmUgYXZvaWRlZCBpZiANCnBvc3NpYmxlLg0KVGhlcmUgYXJlIG90aGVyIHBl b3BsZSB0aGF0IHRoaW5rIHRoYXQgdGhlIE0tYml0IHZhbHVlIGlzIHJlcXVpcmVkIHRvIGJlIA0K dGhlIHNhbWUgaW4gZXZlcnkgaW5zdGFuY2Ugb2YgcmVxdWVzdCBvZiBhbiBzcGVjaWZpYyB0eXBl IGZvciBvbmUgDQphcHBsaWNhdGlvbi4gVGhhdCBpcywgdGhleSB0aGluayB0aGF0IGlmIHRoZSBB VlAgaGFzIHRoZSBNLWJpdCBzZXQgaW4gdGhlIA0KYXV0aGVudGljYXRpb24gcmVxdWVzdCBvZiBh biBhcHBsaWNhdGlvbiwgdGhlbiBpdCBtdXN0IGhhdmUgdGhlIHNhbWUgTS1iaXQgDQp2YWx1ZSBl dmVyeSB0aW1lIHRoaXMgYXV0aGVudGljYXRpb24gcmVxdWVzdCBpcyBzZW50Lg0KQW5kIHRoZXJl IGFyZSB5ZXQgb3RoZXIgcGVvcGxlIHRoYXQgdGhpbmsgdGhhdCB0aGUgdmFsdWUgbXVzdCBiZSB0 aGUgc2FtZSANCmZvciBldmVyeSByZXF1ZXN0IG9mIGV2ZXJ5IHR5cGUgZm9yIG9uZSBhcHBsaWNh dGlvbi4NCkkgaGF2ZW4ndCBtZXQgYW55b25lIHRoYXQgdGhpbmtzIHRoYXQgdGhlIHZhbHVlIG5l ZWRzIHRvIGJlIHRoZSBzYW1lIGZvciANCnRoZSBBVlAgaW4gYWxsIGFwcGxpY2F0aW9ucywgYnV0 IG1heWJlIEkgaGF2ZW4ndCBzZWFyY2ggZW5vdWdoIDotKQ0KUGxlYXNlIGhlbHAgbWUgYnkgdGVs bGluZyBtZSBpZiBJIGFtIHdyb25nIGFuZCB3aHkgb3IgaWYgeW91IHRoaW5rIHRoYXQgDQp0aGVy ZSBhcmUgb3RoZXIgcmVhc29ucyB0byBzdXBwb3J0IG15IHZpZXcuIA0KQnkgdGhlIHdheSwgbWF5 YmUgdGhpcyBpcyB3b3J0aCBhIGNsYXJpZmljYXRpb24gaW4gUkZDMzU4OGJpcy4gDQpUaGFua3Ms IA0KR2VybWFuIEJsYW5jby4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkRpTUUgbWFpbGluZyBsaXN0DQpEaU1FQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCg0KDQoNCioqKioqKioqKioqKioqKioqKioq KioqICBBcmljZW50LVVuY2xhc3NpZmllZCAgICoqKioqKioqKioqKioqKioqKioqKioqDQoNCioq KioqKioqKioqKioqKioqKioqKioqICBBcmljZW50LVVuY2xhc3NpZmllZCAgICoqKioqKioqKioq KioqKioqKioqKioqDQoiRElTQ0xBSU1FUjogVGhpcyBtZXNzYWdlIGlzIHByb3ByaWV0YXJ5IHRv IEFyaWNlbnQgIGFuZCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgCnRoZSBpbmRp dmlkdWFsIHRvIHdob20gaXQgaXMgYWRkcmVzc2VkLiBJdCBtYXkgY29udGFpbiBwcml2aWxlZ2Vk IG9yIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBhbmQgc2hvdWxkIG5vdCBiZSAKY2lyY3VsYXRl ZCBvciB1c2VkIGZvciBhbnkgcHVycG9zZSBvdGhlciB0aGFuIGZvciB3aGF0IGl0IGlzIGludGVu ZGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIApwbGVhc2Ug bm90aWZ5IHRoZSBvcmlnaW5hdG9yIGltbWVkaWF0ZWx5LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIG5vdGlmaWVkIHRoYXQgeW91IGFyZSBzdHJpY3RseQpw cm9oaWJpdGVkIGZyb20gdXNpbmcsIGNvcHlpbmcsIGFsdGVyaW5nLCBvciBkaXNjbG9zaW5nIHRo ZSBjb250ZW50cyBvZiB0aGlzIG1lc3NhZ2UuIEFyaWNlbnQgYWNjZXB0cyBubyByZXNwb25zaWJp bGl0eSBmb3IgCmxvc3Mgb3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0aGUgdXNlIG9mIHRoZSBpbmZv cm1hdGlvbiB0cmFuc21pdHRlZCBieSB0aGlzIGVtYWlsIGluY2x1ZGluZyBkYW1hZ2UgZnJvbSB2 aXJ1cy4iCg== --=_alternative 001A9A1365257402_= Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgYWdyZWUgd2l0aCB5b3UgVG9s Z2EsICZuYnNwO2J1dCBSRkMNCmRvZXMgbm90IG1lbnRpb24gdGhhdCAnQVZQIGZsYWcgcnVsZSBm b3IgdGhlIE0gYml0IGNhbiBuZXZlciBiZSAnTUFZJzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+U28gaWYgTSBiaXQgZm9yIGFueSBBVlAgaXMgbWVudGlv bmVkDQphcyBNQVksIHRoaXMgaW5kaWNhdGVzIHRoYXQgc2VydmVyIG11c3QgcmVjb2duaXplIHRo aXMgQVZQLCBpZiBNIGJpdCBpcw0Kc2V0LiBTZXJ2ZXIgc2hvdWxkIG5vdCBnZW5lcmF0ZSBhbnkg ZXJyb3IgaWYgTSBiaXQgaXMgbm90IHNldCBmb3IgdGhlIHNhbWUNCkFWUDwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+U28gdGhlb3JldGljYWxseSwgaXQg aXMgcG9zc2libGUgdGhhdA0KdGhlcmUgY2FuIGJlIGFuIEFWUCB3aGljaCBjYW4gaGF2ZSBNIGJp dCBzZXQgb3IgTSBiaXQgJ25vdCBzZXQnLiBBbHRob3VnaA0KcHJhY3RpY2FsbHkgSSBkb24ndCBz ZWUgYW55IHNjZW5hcmlvLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+cmVnYXJkczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+UHJlZXRpPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEw MCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD00MCU+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPjxiPiZxdW90O0FzdmVyZW4sIFRvbGdhJnF1b3Q7DQombHQ7dGFzdmVyZW5Ac29u dXNuZXQuY29tJmd0OzwvYj4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj5TZW50IGJ5OiBkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+MDMvMDMvMjAwOCAwOTozMCBQTTwvZm9udD4NCjxicj4NCjx0 ZCB3aWR0aD01OSU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0cj4NCjx0ZD4NCjxkaXYgYWxpZ249 cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlRvPC9mb250PjwvZGl2Pg0KPHRk IHZhbGlnbj10b3A+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O0dlcm1hbiBC bGFuY28mcXVvdDsNCiZsdDtnZXJtYW4uYmxhbmNvQGVyaWNzc29uLmNvbSZndDssICZsdDtkaW1l QGlldGYub3JnJmd0OzwvZm9udD4NCjx0cj4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmNjPC9mb250PjwvZGl2Pg0KPHRkIHZhbGlnbj10b3A+ DQo8dHI+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj5TdWJqZWN0PC9mb250PjwvZGl2Pg0KPHRkIHZhbGlnbj10b3A+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPlJlOiBbRGltZV0gUXVlc3Rpb24gb24gdGhlDQp1c2Ugb2YgdGhlIE0t Yml0PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4N Cjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGNvbG9yPSMwMDAwODAgZmFjZT0iQXJpYWwiPklNSE8sIHdoYXQgeW91IG5lZWQgaXMgYW4gQVZQ DQppbmRpY2F0ZWQgYXMgb3B0aW9uYWwgaW4gQUJORiBidXQgd2l0aCBNLWJpdCBzZXQuIFRoYXQg aXQgaXMgb3B0aW9uYWwgaW4NCkFCTkYgaW5kaWNhdGVzIHRoYXQgaXQgbWF5IG5vdCBiZSBwcmVz ZW50LiBUaGF0IGl0IGhhcyBNLWJpdCBzZXQgaW5kaWNhdGVzDQp0aGF0IGlmIHByZXNlbnQsIGl0 IG5lZWRzIHRvIGJlIHVuZGVyc3Rvb2QvcHJvY2Vzc2VkLjwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgY29sb3I9IzAwMDA4MCBmYWNlPSJBcmlhbCI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBjb2xvcj0jMDAwMDgwIGZhY2U9IkFyaWFsIj5NLWJpdCB2YWx1ZSBmb3IgYW4gQVZQIGNh bg0KY2hhbmdlIGZvciBkaWZmZXJlbnQgY29tbWFuZHMuPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBjb2xvcj0jMDAwMDgwIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQXJpYWwiPlRoYW5rcyw8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQXJpYWwiPlRvbGdhPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBjb2xvcj0jMDAwMDgwIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8ZGl2IGFs aWduPWNlbnRlcj4NCjxicj4NCjxocj48L2Rpdj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGFo b21hIj48Yj5Gcm9tOjwvYj4gZGltZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGltZS1ib3Vu Y2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5HZXJtYW4gQmxhbmNvPGI+PGJyPg0K U2VudDo8L2I+IE1vbmRheSwgTWFyY2ggMDMsIDIwMDggODo0NiBBTTxiPjxicj4NClRvOjwvYj4g ZGltZUBpZXRmLm9yZzxiPjxicj4NClN1YmplY3Q6PC9iPiBbRGltZV0gUXVlc3Rpb24gb24gdGhl IHVzZSBvZiB0aGUgTS1iaXQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5IZWxs byBhbGwsPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250 Pg0KPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5JIGhhdmUgYSB2ZXJ5IHNpbXBsZSBxdWVz dGlvbiBvbiB0aGUgTS1iaXQsDQpwbGVhc2UgaGVscC48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+IDwvZm9udD4NCjxwPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+ TXkgdmlldyBpcyB0aGF0IHRoZSBhcHBsaWNhdGlvbiBtYXkgc2V0IHRoaXMNCmJpdCBmb3IgYW4g QVZQIGluIGFueSBpbnN0YW5jZSBvZiBhbnkgcmVxdWVzdCBpbmRlcGVuZGVudGx5LiBUaGF0IGlz LCB0aGUNCk0tYml0IGlzIHNldCB3aGVuIHRoZSBwZWVyIGlzIHJlcXVpcmVkIHRvIHVuZGVyc3Rh bmQgdGhlIEFWUCwgd2l0aCBubyBvdGhlcg0KY29uZGl0aW9uLiA8L2ZvbnQ+DQo8cD48Zm9udCBz aXplPTIgZmFjZT0iQXJpYWwiPkZvciBleGFtcGxlLCBJIGhhdmUgdGhpcyBBVlAgZm9yIG5hdGlv bmFsaXR5DQpvZiBwZW9wbGUgdGhhdCBJIHVzZSBvbmx5IGZvciBmb3JlaWduZXJzLiBJbiB0aGUg YXV0aGVudGljYXRpb24gcmVxdWVzdA0Kb2YgdGhpcyBhcHBsaWNhdGlvbiBJIHNlbmQgdGhlIG5h dGlvbmFsaXR5IEFWUCB3aXRoIHRoZSBNLWJpdCBzZXQgaWYgdGhlDQpwZXJzb24gaXMgYSBmb3Jl aWduZXIgc2luY2UgdGhlIERpYW1ldGVyIGFwcGxpY2F0aW9uIGluIHRoZSBvdGhlciBwZWVyDQpu ZWVkcyB0byBkbyBzb21ldGhpbmcgc3BlY2lhbCwgYnV0IGlmIHRoZSBwZXJzb24gaXMgbG9jYWwg dGhlbiBJIHNlbmQgdGhlDQpuYXRpb25hbGl0eSBBVlAgd2l0aCB0aGUgTS1iaXQgbm90IHNldCwg c2luY2UgdGhlIGRlZmF1bHQgZnVuY3Rpb25hbGl0eQ0Kd2lsbCB3b3JrLiBJIGFsc28gdGhpbmsg dGhhdCBzaW5jZSB0aGUgZm9sbG93aW5nIHJlc3RyaWN0aW9ucyBhcmUgbm90IGV4cGxpY2l0DQph bnl3aGVyZSB0aGF0IEkgYW0gYXdhcmUsIGFuZCB0aGV5IGRvIG5vdCBzZWVtIHRvIHNlcnZlIGFu eSBwcmFjdGljYWwgcHVycG9zZSwNCnRoZXkgc2hvdWxkIGJlIGF2b2lkZWQgaWYgcG9zc2libGUu PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5UaGVyZSBhcmUgb3RoZXIgcGVv cGxlIHRoYXQgdGhpbmsgdGhhdCB0aGUNCk0tYml0IHZhbHVlIGlzIHJlcXVpcmVkIHRvIGJlIHRo ZSBzYW1lIGluIGV2ZXJ5IGluc3RhbmNlIG9mIHJlcXVlc3Qgb2YNCmFuIHNwZWNpZmljIHR5cGUg Zm9yIG9uZSBhcHBsaWNhdGlvbi4gVGhhdCBpcywgdGhleSB0aGluayB0aGF0IGlmIHRoZSBBVlAN CmhhcyB0aGUgTS1iaXQgc2V0IGluIHRoZSBhdXRoZW50aWNhdGlvbiByZXF1ZXN0IG9mIGFuIGFw cGxpY2F0aW9uLCB0aGVuDQppdCBtdXN0IGhhdmUgdGhlIHNhbWUgTS1iaXQgdmFsdWUgZXZlcnkg dGltZSB0aGlzIGF1dGhlbnRpY2F0aW9uIHJlcXVlc3QNCmlzIHNlbnQuPC9mb250Pg0KPHA+PGZv bnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5BbmQgdGhlcmUgYXJlIHlldCBvdGhlciBwZW9wbGUgdGhh dCB0aGluaw0KdGhhdCB0aGUgdmFsdWUgbXVzdCBiZSB0aGUgc2FtZSBmb3IgZXZlcnkgcmVxdWVz dCBvZiBldmVyeSB0eXBlIGZvciBvbmUNCmFwcGxpY2F0aW9uLjwvZm9udD4NCjxwPjxmb250IHNp emU9MiBmYWNlPSJBcmlhbCI+SSBoYXZlbid0IG1ldCBhbnlvbmUgdGhhdCB0aGlua3MgdGhhdCB0 aGUNCnZhbHVlIG5lZWRzIHRvIGJlIHRoZSBzYW1lIGZvciB0aGUgQVZQIGluIGFsbCBhcHBsaWNh dGlvbnMsIGJ1dCBtYXliZSBJDQpoYXZlbid0IHNlYXJjaCBlbm91Z2ggOi0pPC9mb250Pg0KPHA+ PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5QbGVhc2UgaGVscCBtZSBieSB0ZWxsaW5nIG1lIGlm IEkgYW0gd3JvbmcNCmFuZCB3aHkgb3IgaWYgeW91IHRoaW5rIHRoYXQgdGhlcmUgYXJlIG90aGVy IHJlYXNvbnMgdG8gc3VwcG9ydCBteSB2aWV3LjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+Qnkg dGhlIHdheSwgbWF5YmUgdGhpcyBpcyB3b3J0aCBhIGNsYXJpZmljYXRpb24NCmluIFJGQzM1ODhi aXMuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8L2ZvbnQ+DQo8 cD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPlRoYW5rcyw8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTIgZmFjZT0iQXJp YWwiPkdlcm1hbiBCbGFuY28uIDwvZm9udD48Zm9udCBzaXplPTI+PHR0Pl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KRGlNRSBtYWlsaW5nIGxpc3Q8 YnI+DQpEaU1FQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9kaW1lPGJyPg0KPC90dD48L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+PGJyPg0KPGJyPg0KKioqKioqKioqKioqKioqKioqKioqKiogJm5ic3A7QXJpY2VudC1V bmNsYXNzaWZpZWQgJm5ic3A7ICoqKioqKioqKioqKioqKioqKioqKioqPGJyPg0KPGJyPg0KKioq KioqKioqKioqKioqKioqKioqKiogJm5ic3A7QXJpY2VudC1VbmNsYXNzaWZpZWQgJm5ic3A7ICoq KioqKioqKioqKioqKioqKioqKioqPC9mb250Pg0KPHRhYmxlPjx0cj48dGQgYmdjb2xvcj0jZmZm ZmZmPjxmb250IGNvbG9yPSMwMDAwMDA+PHByZT4iRElTQ0xBSU1FUjogVGhpcyBtZXNzYWdlIGlz IHByb3ByaWV0YXJ5IHRvIEFyaWNlbnQgIGFuZCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1 c2Ugb2YgCnRoZSBpbmRpdmlkdWFsIHRvIHdob20gaXQgaXMgYWRkcmVzc2VkLiBJdCBtYXkgY29u dGFpbiBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBhbmQgc2hvdWxkIG5v dCBiZSAKY2lyY3VsYXRlZCBvciB1c2VkIGZvciBhbnkgcHVycG9zZSBvdGhlciB0aGFuIGZvciB3 aGF0IGl0IGlzIGludGVuZGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4g ZXJyb3IsIApwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIGltbWVkaWF0ZWx5LiBJZiB5b3Ug YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIG5vdGlmaWVkIHRoYXQgeW91 IGFyZSBzdHJpY3RseQpwcm9oaWJpdGVkIGZyb20gdXNpbmcsIGNvcHlpbmcsIGFsdGVyaW5nLCBv ciBkaXNjbG9zaW5nIHRoZSBjb250ZW50cyBvZiB0aGlzIG1lc3NhZ2UuIEFyaWNlbnQgYWNjZXB0 cyBubyByZXNwb25zaWJpbGl0eSBmb3IgCmxvc3Mgb3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0aGUg dXNlIG9mIHRoZSBpbmZvcm1hdGlvbiB0cmFuc21pdHRlZCBieSB0aGlzIGVtYWlsIGluY2x1ZGlu ZyBkYW1hZ2UgZnJvbSB2aXJ1cy4iCjwvcHJlPjwvZm9udD48L3RkPjwvdHI+PC90YWJsZT4= --=_alternative 001A9A1365257402_=-- --===============0082885396== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0082885396==-- From dime-bounces@ietf.org Wed Mar 5 07:15:16 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 339B628C82C; Wed, 5 Mar 2008 07:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.466 X-Spam-Level: X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWu2hxTpu2FP; Wed, 5 Mar 2008 07:15:15 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CA253A6F00; Wed, 5 Mar 2008 07:15:05 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7286F3A6E3E for ; Wed, 5 Mar 2008 07:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rms20JE17ht for ; Wed, 5 Mar 2008 07:15:02 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [61.144.161.54]) by core3.amsl.com (Postfix) with ESMTP id 9905F28C878 for ; Wed, 5 Mar 2008 07:14:32 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JX900DWCJNOBY@szxga02-in.huawei.com> for dime@ietf.org; Wed, 05 Mar 2008 23:14:12 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JX9001DPJNNTY@szxga02-in.huawei.com> for dime@ietf.org; Wed, 05 Mar 2008 23:14:12 +0800 (CST) Received: from huawei1515 ([10.18.23.58]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JX900M2ZJNM9F@szxml03-in.huawei.com> for dime@ietf.org; Wed, 05 Mar 2008 23:14:11 +0800 (CST) Date: Wed, 05 Mar 2008 20:44:10 +0530 From: Rajith R To: dime@ietf.org Message-id: <000601c87ed3$911f3580$3a17120a@china.huawei.com> Organization: htipl MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Thread-index: Ach+05B4P/ugOq59TR+hi1zbn4tJ0A== Subject: [Dime] E bit related issue in rfc-3588-bis-10 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: rajithr@huawei.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Does not "Note that these and only these errors MUST only be used in answer messages whose 'E' bit is set." in section 7.1.3 contradict "In error conditions where it is not possible or efficient to compose application specific answer grammar then answer messages with E-bit set and complying to the grammar described in 7.2 MAY also be used for permanent errors." in section 7.1.5 Rajith _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 5 07:24:30 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D32C228C7D7; Wed, 5 Mar 2008 07:24:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.47 X-Spam-Level: X-Spam-Status: No, score=-0.47 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCys4OKtEWyq; Wed, 5 Mar 2008 07:24:27 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EF7D28C71E; Wed, 5 Mar 2008 07:24:27 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB8E028C7BE for ; Wed, 5 Mar 2008 07:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNkgKfFUqAHs for ; Wed, 5 Mar 2008 07:24:25 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:20e:7fff:fe65:c513]) by core3.amsl.com (Postfix) with ESMTP id E9FD728C71E for ; Wed, 5 Mar 2008 07:24:24 -0800 (PST) Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id m25FNuNq074774; Wed, 5 Mar 2008 10:23:56 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <47CEBAF2.1040007@tari.toshiba.com> Date: Wed, 05 Mar 2008 10:23:30 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: rajithr@huawei.com References: <000601c87ed3$911f3580$3a17120a@china.huawei.com> In-Reply-To: <000601c87ed3$911f3580$3a17120a@china.huawei.com> Cc: dime@ietf.org Subject: Re: [Dime] E bit related issue in rfc-3588-bis-10 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Thanks. The first sentence should have read: "Note that these errors MUST only be used in answer messages whose 'E' bit is set." regards, victor > Does not > "Note that these and only these errors MUST only be used in answer messages > whose 'E' bit is set." in section 7.1.3 contradict > "In error conditions where it is not possible or efficient to compose > application specific answer grammar then answer messages with E-bit set and > complying to the grammar described in 7.2 MAY also be used for permanent > errors." in section 7.1.5 > > Rajith > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 6 00:09:53 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F404A28C6B3; Thu, 6 Mar 2008 00:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.762 X-Spam-Level: X-Spam-Status: No, score=-100.762 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPF2a+O3ynwb; Thu, 6 Mar 2008 00:09:52 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BBE43A6C98; Thu, 6 Mar 2008 00:09:52 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9DEF3A6CC8 for ; Thu, 6 Mar 2008 00:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSbFmmzMwGr0 for ; Thu, 6 Mar 2008 00:09:47 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id B8C3F3A6C98 for ; Thu, 6 Mar 2008 00:09:46 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m2688vqj024819 for ; Thu, 6 Mar 2008 10:09:33 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Mar 2008 10:09:12 +0200 Received: from vaebe101.NOE.Nokia.com ([10.160.244.11]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Mar 2008 10:09:11 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Mar 2008 10:09:10 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DIME Status Update, March 2008 Thread-Index: Ach/YVtgZxvUMX+YQp+I1+Yee45fbw== From: To: X-OriginalArrivalTime: 06 Mar 2008 08:09:11.0950 (UTC) FILETIME=[5C70A2E0:01C87F61] X-Nokia-AV: Clean Subject: [Dime] DIME Status Update, March 2008 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I have created a short status update for DIME on the following page: http://www.shingou.info/twiki/bin/view/Dime/DimeStatusUpdate As said in a previous mail PLEASE change your bookmarks. I have re-designed the content of the page a bit and moved past status reports to the following page: http://www.shingou.info/twiki/bin/view/Dime/DimePastActivities In short, we did some work between the last meeting and this one (more work than most other groups). We have also received new documents for the group to consider. Unfortunately, we could not meet our targets. Hence, if some folks would like to make some progress in the group regarding new documents then the authors should also help us to get the existing stuff finished. Please take a look at it to see whether I missed something. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 6 01:37:11 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D65E28C887; Thu, 6 Mar 2008 01:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.355 X-Spam-Level: X-Spam-Status: No, score=-100.355 tagged_above=-999 required=5 tests=[AWL=-0.918, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iQ7Nolmgcwb; Thu, 6 Mar 2008 01:37:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 094CA28C83E; Thu, 6 Mar 2008 01:37:08 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D12E128C36D; Thu, 6 Mar 2008 01:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLe9Ao3Tn8pG; Thu, 6 Mar 2008 01:37:05 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 0A98F3A68CD; Thu, 6 Mar 2008 01:37:03 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,455,1199660400"; d="scan'208,217";a="2677997" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 06 Mar 2008 10:36:53 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m269arsX004045; Thu, 6 Mar 2008 10:36:53 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m269anHO002696; Thu, 6 Mar 2008 09:36:53 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Mar 2008 10:36:51 +0100 Received: from [10.0.0.92] ([10.61.65.131]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Mar 2008 10:36:47 +0100 In-Reply-To: <714233.34555.qm@web63610.mail.re1.yahoo.com> References: <714233.34555.qm@web63610.mail.re1.yahoo.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <508848E3-230B-40F9-8BFD-F10036348387@cisco.com> From: Francois Le Faucheur IMAP Date: Thu, 6 Mar 2008 10:36:43 +0100 To: Gerald Ash X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 06 Mar 2008 09:36:47.0623 (UTC) FILETIME=[9910B170:01C87F6D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=16940; t=1204796213; x=1205660213; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20[NSIS]=20WG=20last=20call=20on=20draft- ietf-tsvwg-emergency-rsvp-05 |Sender:=20; bh=pflwWxIUUOL59b6d46SxKMvx2MwS8oyZlxUvmEiURYY=; b=ZQmBviOAluPc70p1da7j/sdrcdRoHp+glVO3yDn9d+cjsieujjnUXVMGEh c7fBeNzBBMxZsU0wr41bVEoo/BRdRLZd3TdSO+hLErW5WSRfTt0C0N3+fKuv wVuZ7sFBKz; Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: dime@ietf.org, tsvwg , NSIS Subject: Re: [Dime] [NSIS] WG last call on draft-ietf-tsvwg-emergency-rsvp-05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1448933901==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1448933901== Content-Type: multipart/alternative; boundary=Apple-Mail-11-1003221028 --Apple-Mail-11-1003221028 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hello Jerry, Thanks for the comments. Some answers below: On 5 Mar 2008, at 21:04, Gerald Ash wrote: > All, > > Here are some last call comments on draft-ietf-tsvwg-emergency- > rsvp-05. > > General comments: > > It would be good to motivate the rationale for the emergency-rsvp > approach and why it makes sense to *not* ensure high end-to-end > admission priority across domains for ETS/GETS services. Let me try clarify one more time. The approach is the following: * the overall requirement for Emergency services is to achieve "elevated probability of session establishment" * there are multiple mechanisms (Admission Priority, Preemption, "Call Queueing") that can be combined in different ways in a given network that will ENSURE "elevated probability of session establishment" _through that given network_ * in addition, there is a mechanism allowing each operator to identify an emergency session transiting their network and invoke the corresponding set of mechanism in that network. As a result, the solution allows "elevated probability of session establishment" _end- to-end_, which is the real objective. So, in a nutshell the approach focuses on allowing end-to-end "elevated probability of session establishment" but it is felt that while this may involve admission priority, this does not necessarily dictate end-to-end admission priority. This was discussed at length in the TSVWG. Some operators pointed out that in their region/country Emergency services would use mechanism A while others would use mechanism B, while other would use a combination of mechanisms. Some pointed out that local regulations prevented use of a particular mechanism in a geography while not in another. As agreed by the WG, this discussion was captured in Appendix B illustrating various combinations that an operator may use to achieve "elevated probability of session establishment" . More generally, I think it was felt that IETF was not chartered to mandate a specific combination of mechanisms that MUST be deployed in each and every network. Rather, the IETF needs to make available the mechanisms that can be combined to achieve the end to end objective. [an analogy that comes to mind is the Voice QoS space. The IETF has defined many QoS mechanisms : Diff-Serv, MPLS Traffic Engineering, MPLS FRR, MPLS Diffserv-aware TE, .... However, the IETF does not mandate that a very specific combination of those be used in each and every network carrying voice.] My perception is that the above approach is sufficiently described in the current draft (section 2, appendix B,..). But if you have specific suggestions on how to present it more clearly, we can certainly accommodate that. > > 3. The admission priority approach taken in nsis-qspec (http:// > www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-19.txt) is > consistent with today's practice of providing high admission > priority for ETS/GETS end-to-end across administrative domains. It > does this by standardizing the admission priority values for the > qspec object in an IANA registry, as specified in Section 7 (IANA > considerations): > > "Admission Priority Parameter (8 bits): > The following values are allocated by this specification: > 0-2: assigned as specified in Section 6.2.9: > Admission Priority 0: best-effort priority flow > 1: normal priority flow > 2: high priority flow > The allocation policies for further values are as follows: > 3-63: Standards Action > 64-255: Reserved" > > It has been agreed on the nsis list to rename > to in the qspec draft. To be > consistent with this change, the emergency-rsvp approach should > also be renamed (e.g., to ) to distinguish > it from , and so that neither approach > should be considered a 'generic' approach. I am not sure why the RSVP Admission is no longer generic (it can be used to convey the Y.2171 values if an operator so desires, it can be used to carry other values too). > > 5. Sections A.1 and A.2 illustrate how the DSTE Maximum Allocation > Model (MAM) and the DSTE Russian Dolls Model (RDM) can be used for > support of rsvp admission priority. http://www.amazon.com/Traffic- > Engineering-Optimization-Integrated-Networks/dp/0123706254/ > presents extensive modeling & simulation analysis/case studies to > show how the DSTE maximum allocation with reservation (MAR) model > (http://www.ietf.org/rfc/rfc4126.txt?number=4126) performs for ETS/ > GETS services and how MAR performance compares very favorably to > MAM performance. It would be appropriate to reference MAR as the > third DSTE bandwidth constraints model available for consideration > and perhaps also to reference the MAR/MAM performance analysis > pertinent to emergency services. Yes. We will add a reference to MAR. Francois > > Jerry > > > Magnus Westerlund wrote: > This announces the second WG last call on "Resource ReSerVation > Protovol > (RSVP) Extensions for Emergency Services" with the intended status of > proposed standard: > > http://tools.ietf.org/id/draft-ietf-tsvwg-emergency-rsvp-05.txt > > This is the second one due to changes and the interaction with > documents > in the NSIS and DIME WG. Please provide any comments on the TSVWG > mailing list no later than 28th of March. (Yes, it is long but that is > due to the meeting and that we have several other WG last calls > ongoing). > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www.ietf.org/mailman/listinfo/nsis > > > Never miss a thing. Make Yahoo your homepage. > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www.ietf.org/mailman/listinfo/nsis --Apple-Mail-11-1003221028 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hello Jerry,

Thanks = for the comments. Some answers below:

On 5 Mar = 2008, at 21:04, Gerald Ash wrote:

All,
=A0
Here are some last = call comments on draft-ietf-tsvwg-emergency-rsvp-05.
=A0
=
General comments:
=
=A0
<clip>

It would be good to motivate the = rationale for the emergency-rsvp approach and why it makes sense = to=A0*not* ensure high end-to-end admission priority across domains for = ETS/GETS services.

Let me try clarify one = more time.

The= approach is the following:
* the overall requirement for = Emergency services is to achieve "elevated probability of session = establishment"
* there = are multiple mechanisms (Admission Priority, Preemption, "Call = Queueing") that can be combined in different ways in a given network = that will ENSURE=A0"elevated probability of session establishment" = _through that given network_
* in addition, there is a = mechanism allowing each operator to identify an emergency session = transiting their network and invoke the corresponding set of mechanism = in that network. As a result, the solution allows "elevated probability = of session establishment" _end-to-end_, which is the real = objective.

So,= in a nutshell the approach focuses on allowing end-to-end=A0"elevated = probability of session establishment" but it is felt that while this may = involve admission priority, this does not necessarily dictate end-to-end = admission priority.

This was discussed at = length in the TSVWG. Some operators pointed out that in their = region/country Emergency services=A0would=A0use mechanism A while = others=A0would=A0use mechanism B, while other would use a combination of = mechanisms. Some pointed out that local regulations prevented use of a = particular mechanism in a geography while not in another. As agreed by = the WG, this discussion was captured in Appendix B illustrating various = combinations that an operator may use to achieve=A0"elevated = probability of session establishment" .

More generally, I think it = was felt that=A0IETF was not chartered to mandate a specific combination = of mechanisms that MUST be deployed in each and every network. Rather, = the IETF needs to make available the mechanisms that can be combined to = achieve the end to end objective.
[an analogy that comes to = mind is the Voice QoS space. The IETF has defined many QoS mechanisms : = Diff-Serv, MPLS Traffic Engineering, MPLS FRR, MPLS Diffserv-aware TE, = .... However, the IETF does not mandate that a very specific combination = of those be used in each and every network carrying = voice.]

My = perception is that the above approach is sufficiently described in the = current draft (section 2, appendix B,..). But if you have specific = suggestions on how to present it more clearly, we can = certainly=A0accommodate=A0that.


=A0
3. The admission = priority=A0approach taken in nsis-qspec (= http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-19.txt) = is=A0consistent with today's practice of providing high admission = priority=A0for ETS/GETS end-to-end=A0across administrative domains.=A0 = It does this by standardizing=A0the admission priority values=A0for the = qspec object in an IANA=A0registry, as specified in=A0Section 7 (IANA = considerations):
=A0
=A0=A0"Admission Priority = Parameter (8 bits):
=A0=A0 The following values are allocated by this = specification:
=A0=A0 0-2: assigned as specified in Section = 6.2.9:
=A0=A0 Admission Priority 0: best-effort priority = flow
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = 1: normal priority flow
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 2: high priority flow
=A0=A0 The allocation policies = for further values are as follows:
=A0=A0 3-63: Standards = Action
=A0=A0 64-255: Reserved"
=A0
=
It has been agreed on the=A0nsis list=A0to rename = <Admission Priority> to <Y.2171 Admission Priority> in the = qspec draft.=A0=A0To be consistent with this change, the emergency-rsvp = approach should also=A0be renamed (e.g.,=A0to=A0<RSVP Admission = Priority>) to distinguish it from <Y.2171 Admission Priority>, = and so that neither approach should be considered a 'generic' = approach.

I am not sure why the RSVP = Admission is no longer generic (it can be used to convey the Y.2171 = values if an operator so desires, it can be used to carry other values = too).

=A0
=
5.=A0Sections A.1 and A.2=A0illustrate how the DSTE = Maximum=A0Allocation Model (MAM)=A0and the DSTE Russian Dolls Model = (RDM)=A0can be used for support of rsvp admission priority.=A0 http://www.amazon.com/Traffic-Engineering-Optimization-I= ntegrated-Networks/dp/0123706254/=A0presents extensive = modeling & simulation analysis/case studies=A0to show how the DSTE = maximum allocation with reservation (MAR) model (http://www.ietf= .org/rfc/rfc4126.txt?number=3D4126) performs=A0for ETS/GETS services = and how MAR performance=A0compares very favorably to=A0MAM performance.=A0= It would be appropriate to reference MAR as=A0the third DSTE bandwidth = constraints model available for consideration and=A0perhaps also to = reference the MAR/MAM performance analysis=A0pertinent to=A0emergency = services.

Yes. We will add a = reference to MAR.

Francois

=A0
=
Jerry


Magnus Westerlund <magnus.westerlund@ericsson.= com> wrote:
This announces the second WG last call on "Resource ReSerVation = Protovol
(RSVP) Extensions for Emergency Services" with the intended = status of
proposed standard:

h= ttp://tools.ietf.org/id/draft-ietf-tsvwg-emergency-rsvp-05.txt

= This is the second one due to changes and the interaction with documents =
in the NSIS and DIME WG. Please provide any comments on the TSVWG =
mailing list no later than 28th of March. (Yes, it is long but that = is
due to the meeting and that we have several other WG last calls = ongoing).

Magnus Westerlund

IETF Transport Area Director = & TSVWG = Chair
-----------------------------------------------------------------= -----
Multimedia Technologies, Ericsson Research = EAB/TVM
---------------------------------------------------------------= -------
Ericsson AB | Phone +46 8 4048287
Torshamsgatan 23 | Fax = +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: = magnus.westerlund@ericsson.com
----------------------------------------= ------------------------------

____________________________________= ___________
nsis mailing = list
nsis@ietf.org
https://www.ietf.org/mailman/listinfo/nsis


Never miss a thing. = Make Yahoo your homepage.
nsis mailing list
=

= --Apple-Mail-11-1003221028-- --===============1448933901== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1448933901==-- From dime-bounces@ietf.org Thu Mar 6 02:30:30 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CEE128C888; Thu, 6 Mar 2008 02:30:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.268 X-Spam-Level: X-Spam-Status: No, score=-100.268 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpOqP2POd7Md; Thu, 6 Mar 2008 02:30:29 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CB1128C874; Thu, 6 Mar 2008 02:30:29 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7FAA28C85E; Thu, 6 Mar 2008 02:30:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhdecPmzAUvJ; Thu, 6 Mar 2008 02:30:24 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id A6DB928C874; Thu, 6 Mar 2008 02:30:23 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 53063201A5; Thu, 6 Mar 2008 11:30:12 +0100 (CET) X-AuditID: c1b4fb3e-ad196bb000004ec0-5e-47cfc7b49ffa Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2B900200A4; Thu, 6 Mar 2008 11:30:12 +0100 (CET) Received: from eesmdmw020.eemea.ericsson.se ([159.107.3.34]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Mar 2008 11:30:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Mar 2008 11:30:10 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Question on the use of the M-bit Thread-Index: Ach9s1Zd6xXUgNC0SiCNzJirXMuSjABv+jHQ References: <033458F56EC2A64E8D2D7B759FA3E7E7509868@sonusmail04.sonusnet.com> From: "German Blanco" To: "Preeti Shandilya" , "Asveren, Tolga" X-OriginalArrivalTime: 06 Mar 2008 10:30:11.0717 (UTC) FILETIME=[0EDAA350:01C87F75] X-Brightmail-Tracker: AAAAAA== Cc: dime-bounces@ietf.org, dime@ietf.org Subject: Re: [Dime] Question on the use of the M-bit X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Thank you all for your responses, regarding the scenario, we do have at least an AVP in the Cx Interface in 3GPP TS 29.228 and 29.229 that has the M-bit always set in the requests and never in the answers of the same command. German. ________________________________ From: Preeti Shandilya [mailto:preeti.shandilya@aricent.com] Sent: martes, 04 de marzo de 2008 5:51 To: Asveren, Tolga Cc: dime@ietf.org; dime-bounces@ietf.org; German Blanco Subject: Re: [Dime] Question on the use of the M-bit I agree with you Tolga, but RFC does not mention that 'AVP flag rule for the M bit can never be 'MAY' So if M bit for any AVP is mentioned as MAY, this indicates that server must recognize this AVP, if M bit is set. Server should not generate any error if M bit is not set for the same AVP So theoretically, it is possible that there can be an AVP which can have M bit set or M bit 'not set'. Although practically I don't see any scenario. regards Preeti "Asveren, Tolga" Sent by: dime-bounces@ietf.org 03/03/2008 09:30 PM To "German Blanco" , cc Subject Re: [Dime] Question on the use of the M-bit IMHO, what you need is an AVP indicated as optional in ABNF but with M-bit set. That it is optional in ABNF indicates that it may not be present. That it has M-bit set indicates that if present, it needs to be understood/processed. M-bit value for an AVP can change for different commands. Thanks, Tolga ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of German Blanco Sent: Monday, March 03, 2008 8:46 AM To: dime@ietf.org Subject: [Dime] Question on the use of the M-bit Hello all, I have a very simple question on the M-bit, please help. My view is that the application may set this bit for an AVP in any instance of any request independently. That is, the M-bit is set when the peer is required to understand the AVP, with no other condition. For example, I have this AVP for nationality of people that I use only for foreigners. In the authentication request of this application I send the nationality AVP with the M-bit set if the person is a foreigner since the Diameter application in the other peer needs to do something special, but if the person is local then I send the nationality AVP with the M-bit not set, since the default functionality will work. I also think that since the following restrictions are not explicit anywhere that I am aware, and they do not seem to serve any practical purpose, they should be avoided if possible. There are other people that think that the M-bit value is required to be the same in every instance of request of an specific type for one application. That is, they think that if the AVP has the M-bit set in the authentication request of an application, then it must have the same M-bit value every time this authentication request is sent. And there are yet other people that think that the value must be the same for every request of every type for one application. I haven't met anyone that thinks that the value needs to be the same for the AVP in all applications, but maybe I haven't search enough :-) Please help me by telling me if I am wrong and why or if you think that there are other reasons to support my view. By the way, maybe this is worth a clarification in RFC3588bis. Thanks, German Blanco. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime *********************** Aricent-Unclassified *********************** *********************** Aricent-Unclassified *********************** "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 6 03:19:06 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 477A428C2B2; Thu, 6 Mar 2008 03:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.642 X-Spam-Level: X-Spam-Status: No, score=-100.642 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZojfRb3gg5K; Thu, 6 Mar 2008 03:19:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05A6628C888; Thu, 6 Mar 2008 03:19:05 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4E7A28C3AE for ; Thu, 6 Mar 2008 03:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ta55qhu0+V-B for ; Thu, 6 Mar 2008 03:19:00 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id AE41428C2B2 for ; Thu, 6 Mar 2008 03:18:37 -0800 (PST) Received: (qmail 22266 invoked by uid 0); 6 Mar 2008 11:18:26 -0000 Received: from 192.100.124.219 by www080.gmx.net with HTTP; Thu, 06 Mar 2008 12:18:26 +0100 (CET) Date: Thu, 06 Mar 2008 12:18:26 +0100 From: "Hannes Tschofenig" In-Reply-To: Message-ID: <20080306111826.23450@gmx.net> MIME-Version: 1.0 References: <033458F56EC2A64E8D2D7B759FA3E7E7509868@sonusmail04.sonusnet.com> To: "German Blanco" , tasveren@sonusnet.com, preeti.shandilya@aricent.com X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1/jMzE1SdDjE1m3NJHTSvdeI9gZY8nL2uQ73/pS6c N+klq5FcAXxGW1LazsPIVuhz0mWySh1ryElg== X-GMX-UID: ZLenChJobHIhS4Fb+zU0vkYiJihyalCp Cc: dime-bounces@ietf.org, diameter-extensibility@googlegroups.com, dime@ietf.org Subject: Re: [Dime] Question on the use of the M-bit X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I should also mention that some of the rules for setting M-bits in Diameter might get changed or clarified as we progress with the work on our Diameter Extensibility story. Currently, I would be in favor of the following rules: * M-bit has to be set when the AVP is required in the ABNF (means that it uses the {AVP} indication in the ABNF of a command) Changes to the ABNF of a Command require a new Command Code to be registered. A new command code in an application requires a new Diameter application to be defined. * The AVP flag table column of SHOULD and SHOULD NOT has to be deleted. It does not make a lot of sense. * When an AVP has the M-bit then a new Diameter application has to be defined. When AVPs are imported from other applications then their flag setting needs to be re-evaluated. Hence, you do not necessarily inherit the AVP flag setting unless it makes sense todo so. The M-bit semantic is associated with the specific usage of the AVP rather than with the AVP itself. Usage in a different context might require different treatment. * When an AVP MAY have the M bit set then this has the same implication as having the M bit set with regard to the definition of a new Diameter application. * The M-bit has only relevance for end-to-end usage; There shouldn't be any rule on how intermediaries process AVPs with the M-bit set. They may, however, at any time reject a specific request but that may have very little todo with the usage of a certain M-bit. Anything missing? A note on the usage of the M-bit in the MAY column of the AVP flag table: This can be used to realize the concept of "mandatory to implement but optional to use" when the ABNF indicates that the AVP is non-required (i.e., [AVP]). In contrast when the ANBF says that an AVP is required (i.e., {AVP} + the M-bit is set automatically based on my rules above) then this is an AVP that must be implemented and must be used. Does this make sense? Ciao Hannes -------- Original-Nachricht -------- > Datum: Thu, 6 Mar 2008 11:30:10 +0100 > Von: "German Blanco" > An: "Preeti Shandilya" , "Asveren, Tolga" > CC: dime-bounces@ietf.org, dime@ietf.org > Betreff: Re: [Dime] Question on the use of the M-bit > Thank you all for your responses, > > regarding the scenario, we do have at least an AVP in the Cx Interface > in 3GPP TS 29.228 and 29.229 that has the M-bit always set in the > requests and never in the answers of the same command. > > German. > > ________________________________ > > From: Preeti Shandilya [mailto:preeti.shandilya@aricent.com] > Sent: martes, 04 de marzo de 2008 5:51 > To: Asveren, Tolga > Cc: dime@ietf.org; dime-bounces@ietf.org; German Blanco > Subject: Re: [Dime] Question on the use of the M-bit > > > > I agree with you Tolga, but RFC does not mention that 'AVP flag rule > for the M bit can never be 'MAY' > > So if M bit for any AVP is mentioned as MAY, this indicates that server > must recognize this AVP, if M bit is set. Server should not generate any > error if M bit is not set for the same AVP > > So theoretically, it is possible that there can be an AVP which can have > M bit set or M bit 'not set'. Although practically I don't see any > scenario. > > regards > Preeti > > > > > "Asveren, Tolga" > Sent by: dime-bounces@ietf.org > > 03/03/2008 09:30 PM > > > > To > "German Blanco" , > cc > > Subject > Re: [Dime] Question on the use of the M-bit > > > > > > > IMHO, what you need is an AVP indicated as optional in ABNF but with > M-bit set. That it is optional in ABNF indicates that it may not be > present. That it has M-bit set indicates that if present, it needs to be > understood/processed. > > M-bit value for an AVP can change for different commands. > > Thanks, > Tolga > > > ________________________________ > > > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > German Blanco > Sent: Monday, March 03, 2008 8:46 AM > To: dime@ietf.org > Subject: [Dime] Question on the use of the M-bit > > > Hello all, > > I have a very simple question on the M-bit, please help. > > My view is that the application may set this bit for an AVP in any > instance of any request independently. That is, the M-bit is set when > the peer is required to understand the AVP, with no other condition. > > For example, I have this AVP for nationality of people that I use only > for foreigners. In the authentication request of this application I send > the nationality AVP with the M-bit set if the person is a foreigner > since the Diameter application in the other peer needs to do something > special, but if the person is local then I send the nationality AVP with > the M-bit not set, since the default functionality will work. I also > think that since the following restrictions are not explicit anywhere > that I am aware, and they do not seem to serve any practical purpose, > they should be avoided if possible. > > There are other people that think that the M-bit value is required to be > the same in every instance of request of an specific type for one > application. That is, they think that if the AVP has the M-bit set in > the authentication request of an application, then it must have the same > M-bit value every time this authentication request is sent. > > And there are yet other people that think that the value must be the > same for every request of every type for one application. > > I haven't met anyone that thinks that the value needs to be the same for > the AVP in all applications, but maybe I haven't search enough :-) > > Please help me by telling me if I am wrong and why or if you think that > there are other reasons to support my view. > > By the way, maybe this is worth a clarification in RFC3588bis. > > Thanks, > > German Blanco. _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > > > > *********************** Aricent-Unclassified *********************** > > *********************** Aricent-Unclassified *********************** > "DISCLAIMER: This message is proprietary to Aricent and is intended > solely for the use of > the individual to whom it is addressed. It may contain privileged or > confidential information and should not be > circulated or used for any purpose other than for what it is intended. > If you have received this message in error, > please notify the originator immediately. If you are not the intended > recipient, you are notified that you are strictly > prohibited from using, copying, altering, or disclosing the contents of > this message. Aricent accepts no responsibility for > loss or damage arising from the use of the information transmitted by > this email including damage from virus." > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 6 03:57:35 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82DAB28C89D; Thu, 6 Mar 2008 03:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.839 X-Spam-Level: X-Spam-Status: No, score=-97.839 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, MIME_BASE64_TEXT=1.753, MIME_HTML_MOSTLY=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhVJX9R-vC6W; Thu, 6 Mar 2008 03:57:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACA2E3A6C41; Thu, 6 Mar 2008 03:57:33 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69C0628C841; Thu, 6 Mar 2008 03:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVdRatwiJDS1; Thu, 6 Mar 2008 03:57:30 -0800 (PST) Received: from jaguar.aricent.com (jaguar.aricent.com [61.246.186.17]) by core3.amsl.com (Postfix) with ESMTP id D15B23A68F8; Thu, 6 Mar 2008 03:56:24 -0800 (PST) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id m26BgH91009135; Thu, 6 Mar 2008 17:12:27 +0530 Received: from sandesh.gur.aricent.com (sandesh [10.203.142.21]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id m26BfYFh008859; Thu, 6 Mar 2008 17:11:49 +0530 In-Reply-To: <20080306111826.23450@gmx.net> To: "Hannes Tschofenig" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Preeti Shandilya Date: Thu, 6 Mar 2008 17:24:26 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.5.5|November 30, 2005) at 06/03/2008 05:30:46 PM, Serialize complete at 06/03/2008 05:30:46 PM Cc: dime-bounces@ietf.org, dime@ietf.org, diameter-extensibility@googlegroups.com Subject: Re: [Dime] Question on the use of the M-bit X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0781441225==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============0781441225== Content-Type: multipart/alternative; boundary="=_alternative 004168C165257404_=" This is a multipart message in MIME format. --=_alternative 004168C165257404_= Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: base64 SGkgIQ0KDQpNeSBjb21tZW50cyBpbmxpbmUuDQoNCnJlZ2FyZHMNClByZWV0aQ0KDQoNCg0KIkhh bm5lcyBUc2Nob2ZlbmlnIiA8SGFubmVzLlRzY2hvZmVuaWdAZ214Lm5ldD4gDQpTZW50IGJ5OiBk aW1lLWJvdW5jZXNAaWV0Zi5vcmcNCjAzLzA2LzIwMDggMDQ6NDggUE0NCg0KDQpUbw0KIkdlcm1h biBCbGFuY28iIDxnZXJtYW4uYmxhbmNvQGVyaWNzc29uLmNvbT4sIHRhc3ZlcmVuQHNvbnVzbmV0 LmNvbSwgDQpQcmVldGkgU2hhbmRpbHlhL0hTU0BIU1MNCmNjDQpkaW1lLWJvdW5jZXNAaWV0Zi5v cmcsIGRpYW1ldGVyLWV4dGVuc2liaWxpdHlAZ29vZ2xlZ3JvdXBzLmNvbSwgDQpkaW1lQGlldGYu b3JnDQpTdWJqZWN0DQpSZTogW0RpbWVdIFF1ZXN0aW9uIG9uIHRoZSB1c2Ugb2YgdGhlIE0tYml0 DQoNCg0KDQoNCg0KDQpJIHNob3VsZCBhbHNvIG1lbnRpb24gdGhhdCBzb21lIG9mIHRoZSBydWxl cyBmb3Igc2V0dGluZyBNLWJpdHMgaW4gDQpEaWFtZXRlciBtaWdodCBnZXQgY2hhbmdlZCBvciBj bGFyaWZpZWQgYXMgd2UgcHJvZ3Jlc3Mgd2l0aCB0aGUgd29yayBvbiANCm91ciBEaWFtZXRlciBF eHRlbnNpYmlsaXR5IHN0b3J5LiANCg0KQ3VycmVudGx5LCBJIHdvdWxkIGJlIGluIGZhdm9yIG9m IHRoZSBmb2xsb3dpbmcgcnVsZXM6IA0KDQoqIE0tYml0IGhhcyB0byBiZSBzZXQgd2hlbiB0aGUg QVZQIGlzIHJlcXVpcmVkIGluIHRoZSBBQk5GDQoobWVhbnMgdGhhdCBpdCB1c2VzIHRoZSB7QVZQ fSBpbmRpY2F0aW9uIGluIHRoZSBBQk5GIG9mIGEgY29tbWFuZCkNCkNoYW5nZXMgdG8gdGhlIEFC TkYgb2YgYSBDb21tYW5kIHJlcXVpcmUgYSBuZXcgQ29tbWFuZCBDb2RlIHRvIGJlIA0KcmVnaXN0 ZXJlZC4gQSBuZXcgY29tbWFuZCBjb2RlIGluIGFuIGFwcGxpY2F0aW9uIHJlcXVpcmVzIGEgbmV3 IERpYW1ldGVyIA0KYXBwbGljYXRpb24gdG8gYmUgZGVmaW5lZC4gDQoNClByZWV0aSA+IEkgZ3Vl c3MgdGhpcyBzaGFsbCBsZWFkIHRvIHNvbWUgaW50ZXJvcGVyYWJpbGl0eSBpc3N1ZXMuIGkuZSBu ZXcgDQpub2RlcyBzaGFsbCBtYW5kYXRvcmlseSBzdGFydCBleHBlY3RpbmcgdG8gaGF2ZSBNIGJp dCBzZXQgaW4gdGhlIEFWUCB3aGVuIA0KaXQgcmVjZWl2ZSByZXF1ZXN0IG1lc3NhZ2VzIGZyb20g cGVlciBub2RlcyB3aGljaCBhcmUgdGhlIG9sZGVyIG5vZGVzLg0KDQoqIFRoZSBBVlAgZmxhZyB0 YWJsZSBjb2x1bW4gb2YgU0hPVUxEIGFuZCBTSE9VTEQgTk9UIGhhcyB0byBiZSBkZWxldGVkLiAN Ckl0IGRvZXMgbm90IG1ha2UgYSBsb3Qgb2Ygc2Vuc2UuIA0KDQpQcmVldGkgPiBmaW5lDQoNCiog V2hlbiBhbiBBVlAgaGFzIHRoZSBNLWJpdCB0aGVuIGEgbmV3IERpYW1ldGVyIGFwcGxpY2F0aW9u IGhhcyB0byBiZSANCmRlZmluZWQuIFdoZW4gQVZQcyBhcmUgaW1wb3J0ZWQgZnJvbSBvdGhlciBh cHBsaWNhdGlvbnMgdGhlbiB0aGVpciBmbGFnIA0Kc2V0dGluZyBuZWVkcyB0byBiZSByZS1ldmFs dWF0ZWQuIEhlbmNlLCB5b3UgZG8gbm90IG5lY2Vzc2FyaWx5IGluaGVyaXQgDQp0aGUgQVZQIGZs YWcgc2V0dGluZyB1bmxlc3MgaXQgbWFrZXMgc2Vuc2UgdG9kbyBzby4gVGhlIE0tYml0IHNlbWFu dGljIGlzIA0KYXNzb2NpYXRlZCB3aXRoIHRoZSBzcGVjaWZpYyB1c2FnZSBvZiB0aGUgQVZQIHJh dGhlciB0aGFuIHdpdGggdGhlIEFWUCANCml0c2VsZi4gVXNhZ2UgaW4gYSBkaWZmZXJlbnQgY29u dGV4dCBtaWdodCByZXF1aXJlIGRpZmZlcmVudCB0cmVhdG1lbnQuIA0KDQpQcmVldGkgPiBUaGlz IGluZGljYXRlcyB0aGF0IHRoZXJlIGNhbiBiZSBhbiBBVlAgd2hpY2ggaGFzIE0gYml0IG1hbmRh dG9yeSANCmluIG9uZSBhcHBsaWNhdGlvbiB3aGlsZSBNIGJpdCBub3Qgc2V0IGluIG90aGVyIGFw cGxpY2F0aW9uIGZvciB0aGUgc2FtZSANCkFWUC4gSXMgdGhlIHVuZGVyc3RhbmRpbmcgY29ycmVj dCA/DQoNCiogV2hlbiBhbiBBVlAgTUFZIGhhdmUgdGhlIE0gYml0IHNldCB0aGVuIHRoaXMgaGFz IHRoZSBzYW1lIGltcGxpY2F0aW9uIGFzIA0KaGF2aW5nIHRoZSBNIGJpdCBzZXQgd2l0aCByZWdh cmQgdG8gdGhlIGRlZmluaXRpb24gb2YgYSBuZXcgRGlhbWV0ZXIgDQphcHBsaWNhdGlvbi4gDQoq IFRoZSBNLWJpdCBoYXMgb25seSByZWxldmFuY2UgZm9yIGVuZC10by1lbmQgdXNhZ2U7IFRoZXJl IHNob3VsZG4ndCBiZSANCmFueSBydWxlIG9uIGhvdyBpbnRlcm1lZGlhcmllcyBwcm9jZXNzIEFW UHMgd2l0aCB0aGUgTS1iaXQgc2V0LiBUaGV5IG1heSwgDQpob3dldmVyLCBhdCBhbnkgdGltZSBy ZWplY3QgYSBzcGVjaWZpYyByZXF1ZXN0IGJ1dCB0aGF0IG1heSBoYXZlIHZlcnkgDQpsaXR0bGUg dG9kbyB3aXRoIHRoZSB1c2FnZSBvZiBhIGNlcnRhaW4gTS1iaXQuIA0KDQpQcmVldGkgPiBJIGRv bid0IHRoaW5rIHRoYXQgTSBiaXQgc2hhbGwgYmUgb25seSBmb3IgZW5kLXRvLWVuZCB1c2FnZS4g DQpUaGVyZSBjYW4gYmUgcHJveHksIHJlZGlyZWN0IG5vZGVzIHdoaWNoIG1heSBhY3QgdXBvbiB0 aGUgTSBiaXQgZmxhZyBvZiBhbiANCkFWUC4gDQoNCkFueXRoaW5nIG1pc3Npbmc/IA0KDQoNCkEg bm90ZSBvbiB0aGUgdXNhZ2Ugb2YgdGhlIE0tYml0IGluIHRoZSBNQVkgY29sdW1uIG9mIHRoZSBB VlAgZmxhZyB0YWJsZTogDQpUaGlzIGNhbiBiZSB1c2VkIHRvIHJlYWxpemUgdGhlIGNvbmNlcHQg b2YgIm1hbmRhdG9yeSB0byBpbXBsZW1lbnQgYnV0IA0Kb3B0aW9uYWwgdG8gdXNlIiB3aGVuIHRo ZSBBQk5GIGluZGljYXRlcyB0aGF0IHRoZSBBVlAgaXMgbm9uLXJlcXVpcmVkIA0KKGkuZS4sIFtB VlBdKS4gSW4gY29udHJhc3Qgd2hlbiB0aGUgQU5CRiBzYXlzIHRoYXQgYW4gQVZQIGlzIHJlcXVp cmVkIA0KKGkuZS4sIHtBVlB9ICsgdGhlIE0tYml0IGlzIHNldCBhdXRvbWF0aWNhbGx5IGJhc2Vk IG9uIG15IHJ1bGVzIGFib3ZlKSANCnRoZW4gdGhpcyBpcyBhbiBBVlAgdGhhdCBtdXN0IGJlIGlt cGxlbWVudGVkIGFuZCBtdXN0IGJlIHVzZWQuIA0KDQpEb2VzIHRoaXMgbWFrZSBzZW5zZT8gDQoN CkNpYW8NCkhhbm5lcw0KDQotLS0tLS0tLSBPcmlnaW5hbC1OYWNocmljaHQgLS0tLS0tLS0NCj4g RGF0dW06IFRodSwgNiBNYXIgMjAwOCAxMTozMDoxMCArMDEwMA0KPiBWb246ICJHZXJtYW4gQmxh bmNvIiA8Z2VybWFuLmJsYW5jb0Blcmljc3Nvbi5jb20+DQo+IEFuOiAiUHJlZXRpIFNoYW5kaWx5 YSIgPHByZWV0aS5zaGFuZGlseWFAYXJpY2VudC5jb20+LCAiQXN2ZXJlbiwgVG9sZ2EiIA0KPHRh c3ZlcmVuQHNvbnVzbmV0LmNvbT4NCj4gQ0M6IGRpbWUtYm91bmNlc0BpZXRmLm9yZywgZGltZUBp ZXRmLm9yZw0KPiBCZXRyZWZmOiBSZTogW0RpbWVdIFF1ZXN0aW9uIG9uIHRoZSB1c2Ugb2YgdGhl IE0tYml0DQoNCj4gVGhhbmsgeW91IGFsbCBmb3IgeW91ciByZXNwb25zZXMsDQo+IA0KPiByZWdh cmRpbmcgdGhlIHNjZW5hcmlvLCB3ZSBkbyBoYXZlIGF0IGxlYXN0IGFuIEFWUCBpbiB0aGUgQ3gg SW50ZXJmYWNlDQo+IGluIDNHUFAgVFMgMjkuMjI4IGFuZCAyOS4yMjkgdGhhdCBoYXMgdGhlIE0t Yml0IGFsd2F5cyBzZXQgaW4gdGhlDQo+IHJlcXVlc3RzIGFuZCBuZXZlciBpbiB0aGUgYW5zd2Vy cyBvZiB0aGUgc2FtZSBjb21tYW5kLg0KPiANCj4gR2VybWFuLg0KPiANCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gDQo+IEZyb206IFByZWV0aSBTaGFuZGlseWEgW21haWx0 bzpwcmVldGkuc2hhbmRpbHlhQGFyaWNlbnQuY29tXSANCj4gU2VudDogbWFydGVzLCAwNCBkZSBt YXJ6byBkZSAyMDA4IDU6NTENCj4gVG86IEFzdmVyZW4sIFRvbGdhDQo+IENjOiBkaW1lQGlldGYu b3JnOyBkaW1lLWJvdW5jZXNAaWV0Zi5vcmc7IEdlcm1hbiBCbGFuY28NCj4gU3ViamVjdDogUmU6 IFtEaW1lXSBRdWVzdGlvbiBvbiB0aGUgdXNlIG9mIHRoZSBNLWJpdA0KPiANCj4gDQo+IA0KPiBJ IGFncmVlIHdpdGggeW91IFRvbGdhLCAgYnV0IFJGQyBkb2VzIG5vdCBtZW50aW9uIHRoYXQgJ0FW UCBmbGFnIHJ1bGUNCj4gZm9yIHRoZSBNIGJpdCBjYW4gbmV2ZXIgYmUgJ01BWScgDQo+IA0KPiBT byBpZiBNIGJpdCBmb3IgYW55IEFWUCBpcyBtZW50aW9uZWQgYXMgTUFZLCB0aGlzIGluZGljYXRl cyB0aGF0IHNlcnZlcg0KPiBtdXN0IHJlY29nbml6ZSB0aGlzIEFWUCwgaWYgTSBiaXQgaXMgc2V0 LiBTZXJ2ZXIgc2hvdWxkIG5vdCBnZW5lcmF0ZSBhbnkNCj4gZXJyb3IgaWYgTSBiaXQgaXMgbm90 IHNldCBmb3IgdGhlIHNhbWUgQVZQIA0KPiANCj4gU28gdGhlb3JldGljYWxseSwgaXQgaXMgcG9z c2libGUgdGhhdCB0aGVyZSBjYW4gYmUgYW4gQVZQIHdoaWNoIGNhbiBoYXZlDQo+IE0gYml0IHNl dCBvciBNIGJpdCAnbm90IHNldCcuIEFsdGhvdWdoIHByYWN0aWNhbGx5IEkgZG9uJ3Qgc2VlIGFu eQ0KPiBzY2VuYXJpby4gDQo+IA0KPiByZWdhcmRzIA0KPiBQcmVldGkgDQo+IA0KPiANCj4gDQo+ IA0KPiAiQXN2ZXJlbiwgVG9sZ2EiIDx0YXN2ZXJlbkBzb251c25ldC5jb20+IA0KPiBTZW50IGJ5 OiBkaW1lLWJvdW5jZXNAaWV0Zi5vcmcgDQo+IA0KPiAwMy8wMy8yMDA4IDA5OjMwIFBNIA0KPiAN Cj4gDQo+IA0KPiBUbw0KPiAgICAgICAgICAgICAgICAiR2VybWFuIEJsYW5jbyIgPGdlcm1hbi5i bGFuY29AZXJpY3Nzb24uY29tPiwgDQo8ZGltZUBpZXRmLm9yZz4gDQo+IGNjDQo+IA0KPiBTdWJq ZWN0DQo+ICAgICAgICAgICAgICAgIFJlOiBbRGltZV0gUXVlc3Rpb24gb24gdGhlIHVzZSBvZiB0 aGUgTS1iaXQNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gSU1ITywgd2hhdCB5b3UgbmVlZCBp cyBhbiBBVlAgaW5kaWNhdGVkIGFzIG9wdGlvbmFsIGluIEFCTkYgYnV0IHdpdGgNCj4gTS1iaXQg c2V0LiBUaGF0IGl0IGlzIG9wdGlvbmFsIGluIEFCTkYgaW5kaWNhdGVzIHRoYXQgaXQgbWF5IG5v dCBiZQ0KPiBwcmVzZW50LiBUaGF0IGl0IGhhcyBNLWJpdCBzZXQgaW5kaWNhdGVzIHRoYXQgaWYg cHJlc2VudCwgaXQgbmVlZHMgdG8gYmUNCj4gdW5kZXJzdG9vZC9wcm9jZXNzZWQuIA0KPiANCj4g TS1iaXQgdmFsdWUgZm9yIGFuIEFWUCBjYW4gY2hhbmdlIGZvciBkaWZmZXJlbnQgY29tbWFuZHMu IA0KPiANCj4gVGhhbmtzLCANCj4gVG9sZ2EgDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gDQo+IA0KPiBGcm9tOiBkaW1lLWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBHZXJtYW4gQmxhbmNv DQo+IFNlbnQ6IE1vbmRheSwgTWFyY2ggMDMsIDIwMDggODo0NiBBTQ0KPiBUbzogZGltZUBpZXRm Lm9yZw0KPiBTdWJqZWN0OiBbRGltZV0gUXVlc3Rpb24gb24gdGhlIHVzZSBvZiB0aGUgTS1iaXQg DQo+IA0KPiANCj4gSGVsbG8gYWxsLCANCj4gDQo+IEkgaGF2ZSBhIHZlcnkgc2ltcGxlIHF1ZXN0 aW9uIG9uIHRoZSBNLWJpdCwgcGxlYXNlIGhlbHAuIA0KPiANCj4gTXkgdmlldyBpcyB0aGF0IHRo ZSBhcHBsaWNhdGlvbiBtYXkgc2V0IHRoaXMgYml0IGZvciBhbiBBVlAgaW4gYW55DQo+IGluc3Rh bmNlIG9mIGFueSByZXF1ZXN0IGluZGVwZW5kZW50bHkuIFRoYXQgaXMsIHRoZSBNLWJpdCBpcyBz ZXQgd2hlbg0KPiB0aGUgcGVlciBpcyByZXF1aXJlZCB0byB1bmRlcnN0YW5kIHRoZSBBVlAsIHdp dGggbm8gb3RoZXIgY29uZGl0aW9uLiANCj4gDQo+IEZvciBleGFtcGxlLCBJIGhhdmUgdGhpcyBB VlAgZm9yIG5hdGlvbmFsaXR5IG9mIHBlb3BsZSB0aGF0IEkgdXNlIG9ubHkNCj4gZm9yIGZvcmVp Z25lcnMuIEluIHRoZSBhdXRoZW50aWNhdGlvbiByZXF1ZXN0IG9mIHRoaXMgYXBwbGljYXRpb24g SSBzZW5kDQo+IHRoZSBuYXRpb25hbGl0eSBBVlAgd2l0aCB0aGUgTS1iaXQgc2V0IGlmIHRoZSBw ZXJzb24gaXMgYSBmb3JlaWduZXINCj4gc2luY2UgdGhlIERpYW1ldGVyIGFwcGxpY2F0aW9uIGlu IHRoZSBvdGhlciBwZWVyIG5lZWRzIHRvIGRvIHNvbWV0aGluZw0KPiBzcGVjaWFsLCBidXQgaWYg dGhlIHBlcnNvbiBpcyBsb2NhbCB0aGVuIEkgc2VuZCB0aGUgbmF0aW9uYWxpdHkgQVZQIHdpdGgN Cj4gdGhlIE0tYml0IG5vdCBzZXQsIHNpbmNlIHRoZSBkZWZhdWx0IGZ1bmN0aW9uYWxpdHkgd2ls bCB3b3JrLiBJIGFsc28NCj4gdGhpbmsgdGhhdCBzaW5jZSB0aGUgZm9sbG93aW5nIHJlc3RyaWN0 aW9ucyBhcmUgbm90IGV4cGxpY2l0IGFueXdoZXJlDQo+IHRoYXQgSSBhbSBhd2FyZSwgYW5kIHRo ZXkgZG8gbm90IHNlZW0gdG8gc2VydmUgYW55IHByYWN0aWNhbCBwdXJwb3NlLA0KPiB0aGV5IHNo b3VsZCBiZSBhdm9pZGVkIGlmIHBvc3NpYmxlLiANCj4gDQo+IFRoZXJlIGFyZSBvdGhlciBwZW9w bGUgdGhhdCB0aGluayB0aGF0IHRoZSBNLWJpdCB2YWx1ZSBpcyByZXF1aXJlZCB0byBiZQ0KPiB0 aGUgc2FtZSBpbiBldmVyeSBpbnN0YW5jZSBvZiByZXF1ZXN0IG9mIGFuIHNwZWNpZmljIHR5cGUg Zm9yIG9uZQ0KPiBhcHBsaWNhdGlvbi4gVGhhdCBpcywgdGhleSB0aGluayB0aGF0IGlmIHRoZSBB VlAgaGFzIHRoZSBNLWJpdCBzZXQgaW4NCj4gdGhlIGF1dGhlbnRpY2F0aW9uIHJlcXVlc3Qgb2Yg YW4gYXBwbGljYXRpb24sIHRoZW4gaXQgbXVzdCBoYXZlIHRoZSBzYW1lDQo+IE0tYml0IHZhbHVl IGV2ZXJ5IHRpbWUgdGhpcyBhdXRoZW50aWNhdGlvbiByZXF1ZXN0IGlzIHNlbnQuIA0KPiANCj4g QW5kIHRoZXJlIGFyZSB5ZXQgb3RoZXIgcGVvcGxlIHRoYXQgdGhpbmsgdGhhdCB0aGUgdmFsdWUg bXVzdCBiZSB0aGUNCj4gc2FtZSBmb3IgZXZlcnkgcmVxdWVzdCBvZiBldmVyeSB0eXBlIGZvciBv bmUgYXBwbGljYXRpb24uIA0KPiANCj4gSSBoYXZlbid0IG1ldCBhbnlvbmUgdGhhdCB0aGlua3Mg dGhhdCB0aGUgdmFsdWUgbmVlZHMgdG8gYmUgdGhlIHNhbWUgZm9yDQo+IHRoZSBBVlAgaW4gYWxs IGFwcGxpY2F0aW9ucywgYnV0IG1heWJlIEkgaGF2ZW4ndCBzZWFyY2ggZW5vdWdoIDotKSANCj4g DQo+IFBsZWFzZSBoZWxwIG1lIGJ5IHRlbGxpbmcgbWUgaWYgSSBhbSB3cm9uZyBhbmQgd2h5IG9y IGlmIHlvdSB0aGluayB0aGF0DQo+IHRoZXJlIGFyZSBvdGhlciByZWFzb25zIHRvIHN1cHBvcnQg bXkgdmlldy4gDQo+IA0KPiBCeSB0aGUgd2F5LCBtYXliZSB0aGlzIGlzIHdvcnRoIGEgY2xhcmlm aWNhdGlvbiBpbiBSRkMzNTg4YmlzLiANCj4gDQo+IFRoYW5rcywgDQo+IA0KPiBHZXJtYW4gQmxh bmNvLiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBE aU1FIG1haWxpbmcgbGlzdA0KPiBEaU1FQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZGltZQ0KPiANCj4gDQo+IA0KPiANCj4gKioqKioqKioqKioqKioq KioqKioqKiogIEFyaWNlbnQtVW5jbGFzc2lmaWVkICAgKioqKioqKioqKioqKioqKioqKioqKioN Cj4gDQo+ICoqKioqKioqKioqKioqKioqKioqKioqICBBcmljZW50LVVuY2xhc3NpZmllZCAgICoq KioqKioqKioqKioqKioqKioqKioqIA0KPiAiRElTQ0xBSU1FUjogVGhpcyBtZXNzYWdlIGlzIHBy b3ByaWV0YXJ5IHRvIEFyaWNlbnQgIGFuZCBpcyBpbnRlbmRlZA0KPiBzb2xlbHkgZm9yIHRoZSB1 c2Ugb2YgDQo+IHRoZSBpbmRpdmlkdWFsIHRvIHdob20gaXQgaXMgYWRkcmVzc2VkLiBJdCBtYXkg Y29udGFpbiBwcml2aWxlZ2VkIG9yDQo+IGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBhbmQgc2hv dWxkIG5vdCBiZSANCj4gY2lyY3VsYXRlZCBvciB1c2VkIGZvciBhbnkgcHVycG9zZSBvdGhlciB0 aGFuIGZvciB3aGF0IGl0IGlzIGludGVuZGVkLg0KPiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IG1lc3NhZ2UgaW4gZXJyb3IsIA0KPiBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIGltbWVk aWF0ZWx5LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQNCj4gcmVjaXBpZW50LCB5b3UgYXJl IG5vdGlmaWVkIHRoYXQgeW91IGFyZSBzdHJpY3RseQ0KPiBwcm9oaWJpdGVkIGZyb20gdXNpbmcs IGNvcHlpbmcsIGFsdGVyaW5nLCBvciBkaXNjbG9zaW5nIHRoZSBjb250ZW50cyBvZg0KPiB0aGlz IG1lc3NhZ2UuIEFyaWNlbnQgYWNjZXB0cyBubyByZXNwb25zaWJpbGl0eSBmb3IgDQo+IGxvc3Mg b3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0aGUgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiB0cmFuc21p dHRlZCBieQ0KPiB0aGlzIGVtYWlsIGluY2x1ZGluZyBkYW1hZ2UgZnJvbSB2aXJ1cy4iDQo+IA0K PiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IERpTUUgbWFpbGluZyBsaXN0DQo+IERpTUVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KRGlNRSBtYWlsaW5nIGxpc3QNCkRpTUVAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0KDQoNCg0KKioqKioqKioq KioqKioqKioqKioqKiogIEFyaWNlbnQtUmVzdHJpY3RlZCAgICoqKioqKioqKioqKioqKioqKioq KioqDQoNCioqKioqKioqKioqKioqKioqKioqKioqICBBcmljZW50LVVuY2xhc3NpZmllZCAgICoq KioqKioqKioqKioqKioqKioqKioqDQoiRElTQ0xBSU1FUjogVGhpcyBtZXNzYWdlIGlzIHByb3By aWV0YXJ5IHRvIEFyaWNlbnQgIGFuZCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2Yg CnRoZSBpbmRpdmlkdWFsIHRvIHdob20gaXQgaXMgYWRkcmVzc2VkLiBJdCBtYXkgY29udGFpbiBw cml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBhbmQgc2hvdWxkIG5vdCBiZSAK Y2lyY3VsYXRlZCBvciB1c2VkIGZvciBhbnkgcHVycG9zZSBvdGhlciB0aGFuIGZvciB3aGF0IGl0 IGlzIGludGVuZGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3Is IApwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIGltbWVkaWF0ZWx5LiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIG5vdGlmaWVkIHRoYXQgeW91IGFyZSBz dHJpY3RseQpwcm9oaWJpdGVkIGZyb20gdXNpbmcsIGNvcHlpbmcsIGFsdGVyaW5nLCBvciBkaXNj bG9zaW5nIHRoZSBjb250ZW50cyBvZiB0aGlzIG1lc3NhZ2UuIEFyaWNlbnQgYWNjZXB0cyBubyBy ZXNwb25zaWJpbGl0eSBmb3IgCmxvc3Mgb3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0aGUgdXNlIG9m IHRoZSBpbmZvcm1hdGlvbiB0cmFuc21pdHRlZCBieSB0aGlzIGVtYWlsIGluY2x1ZGluZyBkYW1h Z2UgZnJvbSB2aXJ1cy4iCg== --=_alternative 004168C165257404_= Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpICE8L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk15IGNvbW1lbnRzIGlubGluZS48L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnJlZ2FyZHM8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlByZWV0aTwvZm9udD4NCjxi cj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQg d2lkdGg9NDAlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj4mcXVvdDtIYW5uZXMg VHNjaG9mZW5pZyZxdW90Ow0KJmx0O0hhbm5lcy5Uc2Nob2ZlbmlnQGdteC5uZXQmZ3Q7PC9iPiA8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlNlbnQgYnk6IGRpbWUt Ym91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij4wMy8wNi8yMDA4IDA0OjQ4IFBNPC9mb250Pg0KPGJyPg0KPHRkIHdpZHRoPTU5JT4NCjx0YWJs ZSB3aWR0aD0xMDAlPg0KPHRyPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+VG88L2ZvbnQ+PC9kaXY+DQo8dGQgdmFsaWduPXRvcD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7R2VybWFuIEJsYW5jbyZxdW90Ow0KJmx0O2dl cm1hbi5ibGFuY29AZXJpY3Nzb24uY29tJmd0OywgdGFzdmVyZW5Ac29udXNuZXQuY29tLCBQcmVl dGkgU2hhbmRpbHlhL0hTU0BIU1M8L2ZvbnQ+DQo8dHI+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5jYzwvZm9udD48L2Rpdj4NCjx0ZCB2YWxp Z249dG9wPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5kaW1lLWJvdW5jZXNAaWV0Zi5v cmcsIGRpYW1ldGVyLWV4dGVuc2liaWxpdHlAZ29vZ2xlZ3JvdXBzLmNvbSwNCmRpbWVAaWV0Zi5v cmc8L2ZvbnQ+DQo8dHI+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj5TdWJqZWN0PC9mb250PjwvZGl2Pg0KPHRkIHZhbGlnbj10b3A+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbRGltZV0gUXVlc3Rpb24gb24gdGhlDQp1c2Ug b2YgdGhlIE0tYml0PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yPjx0dD5JIHNob3VsZCBhbHNvIG1lbnRpb24gdGhhdCBzb21lIG9mIHRoZSBydWxl cyBmb3Igc2V0dGluZw0KTS1iaXRzIGluIERpYW1ldGVyIG1pZ2h0IGdldCBjaGFuZ2VkIG9yIGNs YXJpZmllZCBhcyB3ZSBwcm9ncmVzcyB3aXRoIHRoZQ0Kd29yayBvbiBvdXIgRGlhbWV0ZXIgRXh0 ZW5zaWJpbGl0eSBzdG9yeS4gPGJyPg0KPGJyPg0KQ3VycmVudGx5LCBJIHdvdWxkIGJlIGluIGZh dm9yIG9mIHRoZSBmb2xsb3dpbmcgcnVsZXM6IDxicj4NCjxicj4NCiogTS1iaXQgaGFzIHRvIGJl IHNldCB3aGVuIHRoZSBBVlAgaXMgcmVxdWlyZWQgaW4gdGhlIEFCTkY8YnI+DQoobWVhbnMgdGhh dCBpdCB1c2VzIHRoZSB7QVZQfSBpbmRpY2F0aW9uIGluIHRoZSBBQk5GIG9mIGEgY29tbWFuZCk8 YnI+DQpDaGFuZ2VzIHRvIHRoZSBBQk5GIG9mIGEgQ29tbWFuZCByZXF1aXJlIGEgbmV3IENvbW1h bmQgQ29kZSB0byBiZSByZWdpc3RlcmVkLg0KQSBuZXcgY29tbWFuZCBjb2RlIGluIGFuIGFwcGxp Y2F0aW9uIHJlcXVpcmVzIGEgbmV3IERpYW1ldGVyIGFwcGxpY2F0aW9uDQp0byBiZSBkZWZpbmVk LiA8L3R0PjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0PlByZWV0aSAmZ3Q7IEkg Z3Vlc3MgdGhpcyBzaGFsbCBsZWFkIHRvIHNvbWUgaW50ZXJvcGVyYWJpbGl0eQ0KaXNzdWVzLiBp LmUgbmV3IG5vZGVzIHNoYWxsIG1hbmRhdG9yaWx5IHN0YXJ0IGV4cGVjdGluZyB0byBoYXZlIE0g Yml0IHNldA0KaW4gdGhlIEFWUCB3aGVuIGl0IHJlY2VpdmUgcmVxdWVzdCBtZXNzYWdlcyBmcm9t IHBlZXIgbm9kZXMgd2hpY2ggYXJlIHRoZQ0Kb2xkZXIgbm9kZXMuPC90dD48L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yPjx0dD48YnI+DQoqIFRoZSBBVlAgZmxhZyB0YWJsZSBjb2x1bW4gb2YgU0hP VUxEIGFuZCBTSE9VTEQgTk9UIGhhcyB0byBiZSBkZWxldGVkLg0KPGJyPg0KSXQgZG9lcyBub3Qg bWFrZSBhIGxvdCBvZiBzZW5zZS4gPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y Pjx0dD5QcmVldGkgJmd0OyBmaW5lPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD48 YnI+DQoqIFdoZW4gYW4gQVZQIGhhcyB0aGUgTS1iaXQgdGhlbiBhIG5ldyBEaWFtZXRlciBhcHBs aWNhdGlvbiBoYXMgdG8gYmUgZGVmaW5lZC4NCldoZW4gQVZQcyBhcmUgaW1wb3J0ZWQgZnJvbSBv dGhlciBhcHBsaWNhdGlvbnMgdGhlbiB0aGVpciBmbGFnIDxicj4NCnNldHRpbmcgbmVlZHMgdG8g YmUgcmUtZXZhbHVhdGVkLiBIZW5jZSwgeW91IGRvIG5vdCBuZWNlc3NhcmlseSBpbmhlcml0DQp0 aGUgQVZQIGZsYWcgc2V0dGluZyB1bmxlc3MgaXQgbWFrZXMgc2Vuc2UgdG9kbyBzby4gVGhlIE0t Yml0IHNlbWFudGljDQppcyBhc3NvY2lhdGVkIHdpdGggdGhlIHNwZWNpZmljIHVzYWdlIG9mIHRo ZSBBVlAgcmF0aGVyIHRoYW4gd2l0aCB0aGUgQVZQDQppdHNlbGYuIFVzYWdlIGluIGEgZGlmZmVy ZW50IGNvbnRleHQgbWlnaHQgcmVxdWlyZSBkaWZmZXJlbnQgdHJlYXRtZW50Lg0KPC90dD48L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5QcmVldGkgJmd0OyBUaGlzIGluZGljYXRl cyB0aGF0IHRoZXJlIGNhbiBiZSBhbiBBVlANCndoaWNoIGhhcyBNIGJpdCBtYW5kYXRvcnkgaW4g b25lIGFwcGxpY2F0aW9uIHdoaWxlIE0gYml0IG5vdCBzZXQgaW4gb3RoZXINCmFwcGxpY2F0aW9u IGZvciB0aGUgc2FtZSBBVlAuIElzIHRoZSB1bmRlcnN0YW5kaW5nIGNvcnJlY3QgPzwvdHQ+PC9m b250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+PGJyPg0KKiBXaGVuIGFuIEFWUCBNQVkgaGF2ZSB0 aGUgTSBiaXQgc2V0IHRoZW4gdGhpcyBoYXMgdGhlIHNhbWUgaW1wbGljYXRpb24NCmFzIGhhdmlu ZyB0aGUgTSBiaXQgc2V0IHdpdGggcmVnYXJkIHRvIHRoZSBkZWZpbml0aW9uIG9mIGEgbmV3IERp YW1ldGVyDQphcHBsaWNhdGlvbi4gJm5ic3A7PGJyPg0KKiBUaGUgTS1iaXQgaGFzIG9ubHkgcmVs ZXZhbmNlIGZvciBlbmQtdG8tZW5kIHVzYWdlOyBUaGVyZSBzaG91bGRuJ3QgYmUNCmFueSBydWxl IG9uIGhvdyBpbnRlcm1lZGlhcmllcyBwcm9jZXNzIEFWUHMgd2l0aCB0aGUgTS1iaXQgc2V0LiBU aGV5IG1heSwNCmhvd2V2ZXIsIGF0IGFueSB0aW1lIHJlamVjdCBhIHNwZWNpZmljIHJlcXVlc3Qg YnV0IHRoYXQgbWF5IGhhdmUgdmVyeSBsaXR0bGUNCnRvZG8gd2l0aCB0aGUgdXNhZ2Ugb2YgYSBj ZXJ0YWluIE0tYml0LiA8YnI+DQo8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PlBy ZWV0aSAmZ3Q7IEkgZG9uJ3QgdGhpbmsgdGhhdCBNIGJpdCBzaGFsbCBiZSBvbmx5DQpmb3IgZW5k LXRvLWVuZCB1c2FnZS4gVGhlcmUgY2FuIGJlIHByb3h5LCByZWRpcmVjdCBub2RlcyB3aGljaCBt YXkgYWN0DQp1cG9uIHRoZSBNIGJpdCBmbGFnIG9mIGFuIEFWUC4gPC90dD48L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yPjx0dD48YnI+DQpBbnl0aGluZyBtaXNzaW5nPyA8YnI+DQo8YnI+DQo8YnI+ DQpBIG5vdGUgb24gdGhlIHVzYWdlIG9mIHRoZSBNLWJpdCBpbiB0aGUgTUFZIGNvbHVtbiBvZiB0 aGUgQVZQIGZsYWcgdGFibGU6DQpUaGlzIGNhbiBiZSB1c2VkIHRvIHJlYWxpemUgdGhlIGNvbmNl cHQgb2YgJnF1b3Q7bWFuZGF0b3J5IHRvIGltcGxlbWVudA0KYnV0IG9wdGlvbmFsIHRvIHVzZSZx dW90OyB3aGVuIHRoZSBBQk5GIGluZGljYXRlcyB0aGF0IHRoZSBBVlAgaXMgbm9uLXJlcXVpcmVk DQooaS5lLiwgW0FWUF0pLiBJbiBjb250cmFzdCB3aGVuIHRoZSBBTkJGIHNheXMgdGhhdCBhbiBB VlAgaXMgcmVxdWlyZWQgKGkuZS4sDQp7QVZQfSArIHRoZSBNLWJpdCBpcyBzZXQgYXV0b21hdGlj YWxseSBiYXNlZCBvbiBteSBydWxlcyBhYm92ZSkgdGhlbiB0aGlzDQppcyBhbiBBVlAgdGhhdCBt dXN0IGJlIGltcGxlbWVudGVkIGFuZCBtdXN0IGJlIHVzZWQuIDxicj4NCjxicj4NCkRvZXMgdGhp cyBtYWtlIHNlbnNlPyA8YnI+DQo8YnI+DQpDaWFvPGJyPg0KSGFubmVzPGJyPg0KPGJyPg0KLS0t LS0tLS0gT3JpZ2luYWwtTmFjaHJpY2h0IC0tLS0tLS0tPGJyPg0KJmd0OyBEYXR1bTogVGh1LCA2 IE1hciAyMDA4IDExOjMwOjEwICswMTAwPGJyPg0KJmd0OyBWb246ICZxdW90O0dlcm1hbiBCbGFu Y28mcXVvdDsgJmx0O2dlcm1hbi5ibGFuY29AZXJpY3Nzb24uY29tJmd0Ozxicj4NCiZndDsgQW46 ICZxdW90O1ByZWV0aSBTaGFuZGlseWEmcXVvdDsgJmx0O3ByZWV0aS5zaGFuZGlseWFAYXJpY2Vu dC5jb20mZ3Q7LA0KJnF1b3Q7QXN2ZXJlbiwgVG9sZ2EmcXVvdDsgJmx0O3Rhc3ZlcmVuQHNvbnVz bmV0LmNvbSZndDs8YnI+DQomZ3Q7IENDOiBkaW1lLWJvdW5jZXNAaWV0Zi5vcmcsIGRpbWVAaWV0 Zi5vcmc8YnI+DQomZ3Q7IEJldHJlZmY6IFJlOiBbRGltZV0gUXVlc3Rpb24gb24gdGhlIHVzZSBv ZiB0aGUgTS1iaXQ8YnI+DQo8YnI+DQomZ3Q7IFRoYW5rIHlvdSBhbGwgZm9yIHlvdXIgcmVzcG9u c2VzLDxicj4NCiZndDsgJm5ic3A7PGJyPg0KJmd0OyByZWdhcmRpbmcgdGhlIHNjZW5hcmlvLCB3 ZSBkbyBoYXZlIGF0IGxlYXN0IGFuIEFWUCBpbiB0aGUgQ3ggSW50ZXJmYWNlPGJyPg0KJmd0OyBp biAzR1BQIFRTIDI5LjIyOCBhbmQgMjkuMjI5IHRoYXQgaGFzIHRoZSBNLWJpdCBhbHdheXMgc2V0 IGluIHRoZTxicj4NCiZndDsgcmVxdWVzdHMgYW5kIG5ldmVyIGluIHRoZSBhbnN3ZXJzIG9mIHRo ZSBzYW1lIGNvbW1hbmQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEdlcm1hbi48YnI+DQomZ3Q7IDxi cj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IDxicj4N CiZndDsgRnJvbTogUHJlZXRpIFNoYW5kaWx5YSBbbWFpbHRvOnByZWV0aS5zaGFuZGlseWFAYXJp Y2VudC5jb21dIDxicj4NCiZndDsgU2VudDogbWFydGVzLCAwNCBkZSBtYXJ6byBkZSAyMDA4IDU6 NTE8YnI+DQomZ3Q7IFRvOiBBc3ZlcmVuLCBUb2xnYTxicj4NCiZndDsgQ2M6IGRpbWVAaWV0Zi5v cmc7IGRpbWUtYm91bmNlc0BpZXRmLm9yZzsgR2VybWFuIEJsYW5jbzxicj4NCiZndDsgU3ViamVj dDogUmU6IFtEaW1lXSBRdWVzdGlvbiBvbiB0aGUgdXNlIG9mIHRoZSBNLWJpdDxicj4NCiZndDsg PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBhZ3JlZSB3aXRoIHlvdSBUb2xnYSwg Jm5ic3A7YnV0IFJGQyBkb2VzIG5vdCBtZW50aW9uIHRoYXQgJ0FWUCBmbGFnDQpydWxlPGJyPg0K Jmd0OyBmb3IgdGhlIE0gYml0IGNhbiBuZXZlciBiZSAnTUFZJyA8YnI+DQomZ3Q7IDxicj4NCiZn dDsgU28gaWYgTSBiaXQgZm9yIGFueSBBVlAgaXMgbWVudGlvbmVkIGFzIE1BWSwgdGhpcyBpbmRp Y2F0ZXMgdGhhdCBzZXJ2ZXI8YnI+DQomZ3Q7IG11c3QgcmVjb2duaXplIHRoaXMgQVZQLCBpZiBN IGJpdCBpcyBzZXQuIFNlcnZlciBzaG91bGQgbm90IGdlbmVyYXRlDQphbnk8YnI+DQomZ3Q7IGVy cm9yIGlmIE0gYml0IGlzIG5vdCBzZXQgZm9yIHRoZSBzYW1lIEFWUCA8YnI+DQomZ3Q7IDxicj4N CiZndDsgU28gdGhlb3JldGljYWxseSwgaXQgaXMgcG9zc2libGUgdGhhdCB0aGVyZSBjYW4gYmUg YW4gQVZQIHdoaWNoIGNhbg0KaGF2ZTxicj4NCiZndDsgTSBiaXQgc2V0IG9yIE0gYml0ICdub3Qg c2V0Jy4gQWx0aG91Z2ggcHJhY3RpY2FsbHkgSSBkb24ndCBzZWUgYW55PGJyPg0KJmd0OyBzY2Vu YXJpby4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IHJlZ2FyZHMgPGJyPg0KJmd0OyBQcmVldGkgPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZxdW90 O0FzdmVyZW4sIFRvbGdhJnF1b3Q7ICZsdDt0YXN2ZXJlbkBzb251c25ldC5jb20mZ3Q7IDxicj4N CiZndDsgU2VudCBieTogZGltZS1ib3VuY2VzQGlldGYub3JnIDxicj4NCiZndDsgPGJyPg0KJmd0 OyAwMy8wMy8yMDA4IDA5OjMwIFBNIDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7PGJyPg0KJmd0OyBUbzxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtHZXJtYW4NCkJsYW5jbyZxdW90 OyAmbHQ7Z2VybWFuLmJsYW5jb0Blcmljc3Nvbi5jb20mZ3Q7LCAmbHQ7ZGltZUBpZXRmLm9yZyZn dDsNCjxicj4NCiZndDsgY2M8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0KJmd0OyBTdWJqZWN0PGJyPg0K Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO1JlOg0KW0RpbWVdIFF1ZXN0aW9uIG9uIHRoZSB1c2Ugb2YgdGhlIE0tYml0PGJy Pg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsg PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IElNSE8sIHdoYXQgeW91IG5lZWQgaXMgYW4gQVZQIGluZGlj YXRlZCBhcyBvcHRpb25hbCBpbiBBQk5GIGJ1dCB3aXRoPGJyPg0KJmd0OyBNLWJpdCBzZXQuIFRo YXQgaXQgaXMgb3B0aW9uYWwgaW4gQUJORiBpbmRpY2F0ZXMgdGhhdCBpdCBtYXkgbm90IGJlPGJy Pg0KJmd0OyBwcmVzZW50LiBUaGF0IGl0IGhhcyBNLWJpdCBzZXQgaW5kaWNhdGVzIHRoYXQgaWYg cHJlc2VudCwgaXQgbmVlZHMNCnRvIGJlPGJyPg0KJmd0OyB1bmRlcnN0b29kL3Byb2Nlc3NlZC4g PGJyPg0KJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyBNLWJpdCB2YWx1ZSBmb3IgYW4gQVZQIGNhbiBj aGFuZ2UgZm9yIGRpZmZlcmVudCBjb21tYW5kcy4gPGJyPg0KJmd0OyAmbmJzcDsgPGJyPg0KJmd0 OyBUaGFua3MsIDxicj4NCiZndDsgVG9sZ2EgPGJyPg0KJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IDxicj4NCiZndDsgRnJvbTogZGltZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGlt ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCk9mPGJyPg0KJmd0OyBHZXJtYW4gQmxhbmNv PGJyPg0KJmd0OyBTZW50OiBNb25kYXksIE1hcmNoIDAzLCAyMDA4IDg6NDYgQU08YnI+DQomZ3Q7 IFRvOiBkaW1lQGlldGYub3JnPGJyPg0KJmd0OyBTdWJqZWN0OiBbRGltZV0gUXVlc3Rpb24gb24g dGhlIHVzZSBvZiB0aGUgTS1iaXQgPGJyPg0KJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IEhlbGxvIGFsbCwgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgaGF2ZSBhIHZlcnkgc2ltcGxl IHF1ZXN0aW9uIG9uIHRoZSBNLWJpdCwgcGxlYXNlIGhlbHAuIDxicj4NCiZndDsgPGJyPg0KJmd0 OyBNeSB2aWV3IGlzIHRoYXQgdGhlIGFwcGxpY2F0aW9uIG1heSBzZXQgdGhpcyBiaXQgZm9yIGFu IEFWUCBpbiBhbnk8YnI+DQomZ3Q7IGluc3RhbmNlIG9mIGFueSByZXF1ZXN0IGluZGVwZW5kZW50 bHkuIFRoYXQgaXMsIHRoZSBNLWJpdCBpcyBzZXQgd2hlbjxicj4NCiZndDsgdGhlIHBlZXIgaXMg cmVxdWlyZWQgdG8gdW5kZXJzdGFuZCB0aGUgQVZQLCB3aXRoIG5vIG90aGVyIGNvbmRpdGlvbi4N Cjxicj4NCiZndDsgPGJyPg0KJmd0OyBGb3IgZXhhbXBsZSwgSSBoYXZlIHRoaXMgQVZQIGZvciBu YXRpb25hbGl0eSBvZiBwZW9wbGUgdGhhdCBJIHVzZQ0Kb25seTxicj4NCiZndDsgZm9yIGZvcmVp Z25lcnMuIEluIHRoZSBhdXRoZW50aWNhdGlvbiByZXF1ZXN0IG9mIHRoaXMgYXBwbGljYXRpb24N Ckkgc2VuZDxicj4NCiZndDsgdGhlIG5hdGlvbmFsaXR5IEFWUCB3aXRoIHRoZSBNLWJpdCBzZXQg aWYgdGhlIHBlcnNvbiBpcyBhIGZvcmVpZ25lcjxicj4NCiZndDsgc2luY2UgdGhlIERpYW1ldGVy IGFwcGxpY2F0aW9uIGluIHRoZSBvdGhlciBwZWVyIG5lZWRzIHRvIGRvIHNvbWV0aGluZzxicj4N CiZndDsgc3BlY2lhbCwgYnV0IGlmIHRoZSBwZXJzb24gaXMgbG9jYWwgdGhlbiBJIHNlbmQgdGhl IG5hdGlvbmFsaXR5IEFWUA0Kd2l0aDxicj4NCiZndDsgdGhlIE0tYml0IG5vdCBzZXQsIHNpbmNl IHRoZSBkZWZhdWx0IGZ1bmN0aW9uYWxpdHkgd2lsbCB3b3JrLiBJIGFsc288YnI+DQomZ3Q7IHRo aW5rIHRoYXQgc2luY2UgdGhlIGZvbGxvd2luZyByZXN0cmljdGlvbnMgYXJlIG5vdCBleHBsaWNp dCBhbnl3aGVyZTxicj4NCiZndDsgdGhhdCBJIGFtIGF3YXJlLCBhbmQgdGhleSBkbyBub3Qgc2Vl bSB0byBzZXJ2ZSBhbnkgcHJhY3RpY2FsIHB1cnBvc2UsPGJyPg0KJmd0OyB0aGV5IHNob3VsZCBi ZSBhdm9pZGVkIGlmIHBvc3NpYmxlLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlcmUgYXJlIG90 aGVyIHBlb3BsZSB0aGF0IHRoaW5rIHRoYXQgdGhlIE0tYml0IHZhbHVlIGlzIHJlcXVpcmVkDQp0 byBiZTxicj4NCiZndDsgdGhlIHNhbWUgaW4gZXZlcnkgaW5zdGFuY2Ugb2YgcmVxdWVzdCBvZiBh biBzcGVjaWZpYyB0eXBlIGZvciBvbmU8YnI+DQomZ3Q7IGFwcGxpY2F0aW9uLiBUaGF0IGlzLCB0 aGV5IHRoaW5rIHRoYXQgaWYgdGhlIEFWUCBoYXMgdGhlIE0tYml0IHNldA0KaW48YnI+DQomZ3Q7 IHRoZSBhdXRoZW50aWNhdGlvbiByZXF1ZXN0IG9mIGFuIGFwcGxpY2F0aW9uLCB0aGVuIGl0IG11 c3QgaGF2ZSB0aGUNCnNhbWU8YnI+DQomZ3Q7IE0tYml0IHZhbHVlIGV2ZXJ5IHRpbWUgdGhpcyBh dXRoZW50aWNhdGlvbiByZXF1ZXN0IGlzIHNlbnQuIDxicj4NCiZndDsgPGJyPg0KJmd0OyBBbmQg dGhlcmUgYXJlIHlldCBvdGhlciBwZW9wbGUgdGhhdCB0aGluayB0aGF0IHRoZSB2YWx1ZSBtdXN0 IGJlIHRoZTxicj4NCiZndDsgc2FtZSBmb3IgZXZlcnkgcmVxdWVzdCBvZiBldmVyeSB0eXBlIGZv ciBvbmUgYXBwbGljYXRpb24uIDxicj4NCiZndDsgPGJyPg0KJmd0OyBJIGhhdmVuJ3QgbWV0IGFu eW9uZSB0aGF0IHRoaW5rcyB0aGF0IHRoZSB2YWx1ZSBuZWVkcyB0byBiZSB0aGUgc2FtZQ0KZm9y PGJyPg0KJmd0OyB0aGUgQVZQIGluIGFsbCBhcHBsaWNhdGlvbnMsIGJ1dCBtYXliZSBJIGhhdmVu J3Qgc2VhcmNoIGVub3VnaCA6LSkNCjxicj4NCiZndDsgPGJyPg0KJmd0OyBQbGVhc2UgaGVscCBt ZSBieSB0ZWxsaW5nIG1lIGlmIEkgYW0gd3JvbmcgYW5kIHdoeSBvciBpZiB5b3UgdGhpbmsNCnRo YXQ8YnI+DQomZ3Q7IHRoZXJlIGFyZSBvdGhlciByZWFzb25zIHRvIHN1cHBvcnQgbXkgdmlldy4g PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEJ5IHRoZSB3YXksIG1heWJlIHRoaXMgaXMgd29ydGggYSBj bGFyaWZpY2F0aW9uIGluIFJGQzM1ODhiaXMuIDxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGFua3Ms IDxicj4NCiZndDsgPGJyPg0KJmd0OyBHZXJtYW4gQmxhbmNvLiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgRGlNRSBtYWlsaW5nIGxpc3Q8 YnI+DQomZ3Q7IERpTUVAaWV0Zi5vcmc8YnI+DQomZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZGltZTxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4N CiZndDsgPGJyPg0KJmd0OyAqKioqKioqKioqKioqKioqKioqKioqKiAmbmJzcDtBcmljZW50LVVu Y2xhc3NpZmllZCAmbmJzcDsgKioqKioqKioqKioqKioqKioqKioqKio8YnI+DQomZ3Q7IDxicj4N CiZndDsgKioqKioqKioqKioqKioqKioqKioqKiogJm5ic3A7QXJpY2VudC1VbmNsYXNzaWZpZWQg Jm5ic3A7ICoqKioqKioqKioqKioqKioqKioqKioqDQo8YnI+DQomZ3Q7ICZxdW90O0RJU0NMQUlN RVI6IFRoaXMgbWVzc2FnZSBpcyBwcm9wcmlldGFyeSB0byBBcmljZW50ICZuYnNwO2FuZA0KaXMg aW50ZW5kZWQ8YnI+DQomZ3Q7IHNvbGVseSBmb3IgdGhlIHVzZSBvZiA8YnI+DQomZ3Q7IHRoZSBp bmRpdmlkdWFsIHRvIHdob20gaXQgaXMgYWRkcmVzc2VkLiBJdCBtYXkgY29udGFpbiBwcml2aWxl Z2VkDQpvcjxicj4NCiZndDsgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGFuZCBzaG91bGQgbm90 IGJlIDxicj4NCiZndDsgY2lyY3VsYXRlZCBvciB1c2VkIGZvciBhbnkgcHVycG9zZSBvdGhlciB0 aGFuIGZvciB3aGF0IGl0IGlzIGludGVuZGVkLjxicj4NCiZndDsgSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCA8YnI+DQomZ3Q7IHBsZWFzZSBub3RpZnkgdGhlIG9y aWdpbmF0b3IgaW1tZWRpYXRlbHkuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZDxicj4NCiZn dDsgcmVjaXBpZW50LCB5b3UgYXJlIG5vdGlmaWVkIHRoYXQgeW91IGFyZSBzdHJpY3RseTxicj4N CiZndDsgcHJvaGliaXRlZCBmcm9tIHVzaW5nLCBjb3B5aW5nLCBhbHRlcmluZywgb3IgZGlzY2xv c2luZyB0aGUgY29udGVudHMNCm9mPGJyPg0KJmd0OyB0aGlzIG1lc3NhZ2UuIEFyaWNlbnQgYWNj ZXB0cyBubyByZXNwb25zaWJpbGl0eSBmb3IgPGJyPg0KJmd0OyBsb3NzIG9yIGRhbWFnZSBhcmlz aW5nIGZyb20gdGhlIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gdHJhbnNtaXR0ZWQNCmJ5PGJyPg0K Jmd0OyB0aGlzIGVtYWlsIGluY2x1ZGluZyBkYW1hZ2UgZnJvbSB2aXJ1cy4mcXVvdDs8YnI+DQom Z3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IERpTUUgbWFpbGluZyBs aXN0PGJyPg0KJmd0OyBEaU1FQGlldGYub3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2RpbWU8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCkRpTUUgbWFpbGluZyBsaXN0PGJyPg0KRGlNRUBpZXRm Lm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZTxicj4N CjwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8 YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKiAmbmJzcDtBcmljZW50LVJlc3RyaWN0ZWQgJm5i c3A7ICoqKioqKioqKioqKioqKioqKioqKioqPGJyPg0KPGJyPg0KKioqKioqKioqKioqKioqKioq KioqKiogJm5ic3A7QXJpY2VudC1VbmNsYXNzaWZpZWQgJm5ic3A7ICoqKioqKioqKioqKioqKioq KioqKioqPC9mb250Pg0KPHRhYmxlPjx0cj48dGQgYmdjb2xvcj0jZmZmZmZmPjxmb250IGNvbG9y PSMwMDAwMDA+PHByZT4iRElTQ0xBSU1FUjogVGhpcyBtZXNzYWdlIGlzIHByb3ByaWV0YXJ5IHRv IEFyaWNlbnQgIGFuZCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgCnRoZSBpbmRp dmlkdWFsIHRvIHdob20gaXQgaXMgYWRkcmVzc2VkLiBJdCBtYXkgY29udGFpbiBwcml2aWxlZ2Vk IG9yIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBhbmQgc2hvdWxkIG5vdCBiZSAKY2lyY3VsYXRl ZCBvciB1c2VkIGZvciBhbnkgcHVycG9zZSBvdGhlciB0aGFuIGZvciB3aGF0IGl0IGlzIGludGVu ZGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIApwbGVhc2Ug bm90aWZ5IHRoZSBvcmlnaW5hdG9yIGltbWVkaWF0ZWx5LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIG5vdGlmaWVkIHRoYXQgeW91IGFyZSBzdHJpY3RseQpw cm9oaWJpdGVkIGZyb20gdXNpbmcsIGNvcHlpbmcsIGFsdGVyaW5nLCBvciBkaXNjbG9zaW5nIHRo ZSBjb250ZW50cyBvZiB0aGlzIG1lc3NhZ2UuIEFyaWNlbnQgYWNjZXB0cyBubyByZXNwb25zaWJp bGl0eSBmb3IgCmxvc3Mgb3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0aGUgdXNlIG9mIHRoZSBpbmZv cm1hdGlvbiB0cmFuc21pdHRlZCBieSB0aGlzIGVtYWlsIGluY2x1ZGluZyBkYW1hZ2UgZnJvbSB2 aXJ1cy4iCjwvcHJlPjwvZm9udD48L3RkPjwvdHI+PC90YWJsZT4= --=_alternative 004168C165257404_=-- --===============0781441225== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0781441225==-- From dime-bounces@ietf.org Thu Mar 6 04:29:13 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ECCC3A6D82; Thu, 6 Mar 2008 04:29:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.976 X-Spam-Level: X-Spam-Status: No, score=-100.976 tagged_above=-999 required=5 tests=[AWL=-0.539, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaSDJAUx6fEE; Thu, 6 Mar 2008 04:29:12 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D2403A6F2F; Thu, 6 Mar 2008 04:29:12 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96BC43A6D82; Thu, 6 Mar 2008 04:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-VG6AnXHUVN; Thu, 6 Mar 2008 04:29:07 -0800 (PST) Received: from sehan002bb.han.telia.se (sehan002bb.han.telia.se [131.115.18.153]) by core3.amsl.com (Postfix) with ESMTP id B9B7E3A6F59; Thu, 6 Mar 2008 04:29:05 -0800 (PST) Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Mar 2008 13:28:52 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Mar 2008 13:28:53 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30288B2E9@SEHAN021MB.tcad.telia.se> In-Reply-To: <20080306111826.23450@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Question on the use of the M-bit Thread-Index: Ach/e+OhHm5z5vSBRn6idVSZSPhUegACNZyw References: <033458F56EC2A64E8D2D7B759FA3E7E7509868@sonusmail04.sonusnet.com> <20080306111826.23450@gmx.net> From: To: , , , X-OriginalArrivalTime: 06 Mar 2008 12:28:52.0489 (UTC) FILETIME=[A32A3790:01C87F85] Cc: dime-bounces@ietf.org, dime@ietf.org, diameter-extensibility@googlegroups.com Subject: Re: [Dime] Question on the use of the M-bit X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hannes, Some comments inline. > I should also mention that some of the rules for setting > M-bits in Diameter might get changed or clarified as we > progress with the work on our Diameter Extensibility story. > > Currently, I would be in favor of the following rules: > > * M-bit has to be set when the AVP is required in the ABNF > (means that it uses the {AVP} indication in the ABNF of a command) > Changes to the ABNF of a Command require a new Command Code > to be registered. A new command code in an application > requires a new Diameter application to be defined. Ok. I wonder if there is any existing specification that has { AVP } without M-bit set? > * The AVP flag table column of SHOULD and SHOULD NOT has to > be deleted. > It does not make a lot of sense. > * When an AVP has the M-bit then a new Diameter application > has to be defined. When AVPs are imported from other > applications then their flag > setting needs to be re-evaluated. Hence, you do not > necessarily inherit the AVP flag setting unless it makes > sense todo so. The M-bit semantic is associated with the > specific usage of the AVP rather than with the AVP itself. > Usage in a different context might require different treatment. > * When an AVP MAY have the M bit set then this has the same > implication as having the M bit set with regard to the > definition of a new Diameter application. > * The M-bit has only relevance for end-to-end usage; There > shouldn't be any rule on how intermediaries process AVPs with > the M-bit set. They may, however, at any time reject a > specific request but that may have very little todo with the > usage of a certain M-bit. Proxies need to understand the applications and sometimes process the messages, thus M-bit is not only for end-to-end usage. Cheers, Jouni > Anything missing? > > > A note on the usage of the M-bit in the MAY column of the AVP > flag table: This can be used to realize the concept of > "mandatory to implement but optional to use" when the ABNF > indicates that the AVP is non-required (i.e., [AVP]). In > contrast when the ANBF says that an AVP is required (i.e., > {AVP} + the M-bit is set automatically based on my rules > above) then this is an AVP that must be implemented and must be used. > > Does this make sense? > > Ciao > Hannes > > -------- Original-Nachricht -------- > > Datum: Thu, 6 Mar 2008 11:30:10 +0100 > > Von: "German Blanco" > > An: "Preeti Shandilya" , > "Asveren, Tolga" > > CC: dime-bounces@ietf.org, dime@ietf.org > > Betreff: Re: [Dime] Question on the use of the M-bit > > > Thank you all for your responses, > > > > regarding the scenario, we do have at least an AVP in the > Cx Interface > > in 3GPP TS 29.228 and 29.229 that has the M-bit always set in the > > requests and never in the answers of the same command. > > > > German. > > > > ________________________________ > > > > From: Preeti Shandilya [mailto:preeti.shandilya@aricent.com] > > Sent: martes, 04 de marzo de 2008 5:51 > > To: Asveren, Tolga > > Cc: dime@ietf.org; dime-bounces@ietf.org; German Blanco > > Subject: Re: [Dime] Question on the use of the M-bit > > > > > > > > I agree with you Tolga, but RFC does not mention that 'AVP > flag rule > > for the M bit can never be 'MAY' > > > > So if M bit for any AVP is mentioned as MAY, this indicates > that server > > must recognize this AVP, if M bit is set. Server should not > generate any > > error if M bit is not set for the same AVP > > > > So theoretically, it is possible that there can be an AVP > which can have > > M bit set or M bit 'not set'. Although practically I don't see any > > scenario. > > > > regards > > Preeti > > > > > > > > > > "Asveren, Tolga" > > Sent by: dime-bounces@ietf.org > > > > 03/03/2008 09:30 PM > > > > > > > > To > > "German Blanco" , > > cc > > > > Subject > > Re: [Dime] Question on the use of the M-bit > > > > > > > > > > > > > > IMHO, what you need is an AVP indicated as optional in ABNF but with > > M-bit set. That it is optional in ABNF indicates that it may not be > > present. That it has M-bit set indicates that if present, > it needs to be > > understood/processed. > > > > M-bit value for an AVP can change for different commands. > > > > Thanks, > > Tolga > > > > > > ________________________________ > > > > > > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] > On Behalf Of > > German Blanco > > Sent: Monday, March 03, 2008 8:46 AM > > To: dime@ietf.org > > Subject: [Dime] Question on the use of the M-bit > > > > > > Hello all, > > > > I have a very simple question on the M-bit, please help. > > > > My view is that the application may set this bit for an AVP in any > > instance of any request independently. That is, the M-bit > is set when > > the peer is required to understand the AVP, with no other > condition. > > > > For example, I have this AVP for nationality of people that > I use only > > for foreigners. In the authentication request of this > application I send > > the nationality AVP with the M-bit set if the person is a foreigner > > since the Diameter application in the other peer needs to > do something > > special, but if the person is local then I send the > nationality AVP with > > the M-bit not set, since the default functionality will work. I also > > think that since the following restrictions are not > explicit anywhere > > that I am aware, and they do not seem to serve any > practical purpose, > > they should be avoided if possible. > > > > There are other people that think that the M-bit value is > required to be > > the same in every instance of request of an specific type for one > > application. That is, they think that if the AVP has the > M-bit set in > > the authentication request of an application, then it must > have the same > > M-bit value every time this authentication request is sent. > > > > And there are yet other people that think that the value must be the > > same for every request of every type for one application. > > > > I haven't met anyone that thinks that the value needs to be > the same for > > the AVP in all applications, but maybe I haven't search enough :-) > > > > Please help me by telling me if I am wrong and why or if > you think that > > there are other reasons to support my view. > > > > By the way, maybe this is worth a clarification in RFC3588bis. > > > > Thanks, > > > > German Blanco. _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > > > > > > > > *********************** Aricent-Unclassified > *********************** > > > > *********************** Aricent-Unclassified > *********************** > > "DISCLAIMER: This message is proprietary to Aricent and is intended > > solely for the use of > > the individual to whom it is addressed. It may contain privileged or > > confidential information and should not be > > circulated or used for any purpose other than for what it > is intended. > > If you have received this message in error, > > please notify the originator immediately. If you are not > the intended > > recipient, you are notified that you are strictly > > prohibited from using, copying, altering, or disclosing the > contents of > > this message. Aricent accepts no responsibility for > > loss or damage arising from the use of the information > transmitted by > > this email including damage from virus." > > > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 6 05:30:13 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B58DB28C4CD; Thu, 6 Mar 2008 05:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.467 X-Spam-Level: X-Spam-Status: No, score=-100.467 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ok-JnqGif8xk; Thu, 6 Mar 2008 05:30:12 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E60883A6E34; Thu, 6 Mar 2008 05:30:12 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF7F13A6EB6; Thu, 6 Mar 2008 05:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Kfme1quU20u; Thu, 6 Mar 2008 05:30:11 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:20e:7fff:fe65:c513]) by core3.amsl.com (Postfix) with ESMTP id 084C43A6D82; Thu, 6 Mar 2008 05:30:10 -0800 (PST) Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id m26DTQcd079625; Thu, 6 Mar 2008 08:29:26 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <47CFF1A1.9090903@tari.toshiba.com> Date: Thu, 06 Mar 2008 08:29:05 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: jouni.korhonen@teliasonera.com References: <033458F56EC2A64E8D2D7B759FA3E7E7509868@sonusmail04.sonusnet.com> <20080306111826.23450@gmx.net> <59D7431DE2527D4CB0F1EFEDA5683ED30288B2E9@SEHAN021MB.tcad.telia.se> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED30288B2E9@SEHAN021MB.tcad.telia.se> Cc: dime-bounces@ietf.org, preeti.shandilya@aricent.com, dime@ietf.org, diameter-extensibility@googlegroups.com Subject: Re: [Dime] Question on the use of the M-bit X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Jouni, > >> * The AVP flag table column of SHOULD and SHOULD NOT has to >> be deleted. >> It does not make a lot of sense. >> * When an AVP has the M-bit then a new Diameter application >> has to be defined. When AVPs are imported from other >> applications then their flag >> setting needs to be re-evaluated. Hence, you do not >> necessarily inherit the AVP flag setting unless it makes >> sense todo so. The M-bit semantic is associated with the >> specific usage of the AVP rather than with the AVP itself. >> Usage in a different context might require different treatment. >> * When an AVP MAY have the M bit set then this has the same >> implication as having the M bit set with regard to the >> definition of a new Diameter application. >> * The M-bit has only relevance for end-to-end usage; There >> shouldn't be any rule on how intermediaries process AVPs with >> the M-bit set. They may, however, at any time reject a >> specific request but that may have very little todo with the >> usage of a certain M-bit. >> > > Proxies need to understand the applications and sometimes process > the messages, thus M-bit is not only for end-to-end usage. > > For proxies, it MAY perform M-bit checks for applications/messages it is interested in just like end-points do. But I guess the point is that there is no hard rule that all intermediaries MUST do M-bit checks. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 6 06:16:33 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B19228C592; Thu, 6 Mar 2008 06:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.228 X-Spam-Level: X-Spam-Status: No, score=-101.228 tagged_above=-999 required=5 tests=[AWL=-0.790, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lX-BdMtfFkNb; Thu, 6 Mar 2008 06:16:32 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3627628C5BC; Thu, 6 Mar 2008 06:16:32 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA9863A69E9; Thu, 6 Mar 2008 06:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsesiQk7q1yU; Thu, 6 Mar 2008 06:16:30 -0800 (PST) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by core3.amsl.com (Postfix) with ESMTP id DD2D728C4FC; Thu, 6 Mar 2008 06:16:29 -0800 (PST) Received: from [88.114.172.224] (a88-114-172-224.elisa-laajakaista.fi [88.114.172.224]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw03.mail.saunalahti.fi (Postfix) with ESMTP id 1F239216344; Thu, 6 Mar 2008 16:16:11 +0200 (EET) In-Reply-To: <47CFF1A1.9090903@tari.toshiba.com> References: <033458F56EC2A64E8D2D7B759FA3E7E7509868@sonusmail04.sonusnet.com> <20080306111826.23450@gmx.net> <59D7431DE2527D4CB0F1EFEDA5683ED30288B2E9@SEHAN021MB.tcad.telia.se> <47CFF1A1.9090903@tari.toshiba.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Jouni Korhonen Date: Thu, 6 Mar 2008 16:16:07 +0200 To: Victor Fajardo X-Mailer: Apple Mail (2.753) Cc: dime-bounces@ietf.org, diameter-extensibility@googlegroups.com, preeti.shandilya@aricent.com, dime@ietf.org Subject: Re: [Dime] Question on the use of the M-bit X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Victor, On Mar 6, 2008, at 3:29 PM, Victor Fajardo wrote: > Hi Jouni, > >> >>> * The M-bit has only relevance for end-to-end usage; There >>> shouldn't be any rule on how intermediaries process AVPs with >>> the M-bit set. They may, however, at any time reject a >>> specific request but that may have very little todo with the >>> usage of a certain M-bit. >>> >> >> Proxies need to understand the applications and sometimes process >> the messages, thus M-bit is not only for end-to-end usage. >> > For proxies, it MAY perform M-bit checks for applications/messages > it is > interested in just like end-points do. But I guess the point is that > there is no hard rule that all intermediaries MUST do M-bit checks. Yes, I understand that. I just reacted to the strong statement "has only relevance", which is not the case in all situations. "MAY perform.." is much better. Cheers, Jouni > regards, > victor _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 6 12:16:51 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BE5628C811; Thu, 6 Mar 2008 12:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.483 X-Spam-Level: X-Spam-Status: No, score=-99.483 tagged_above=-999 required=5 tests=[AWL=-1.346, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MANGLED_SAVELE=2.3, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7vOlRABeamk; Thu, 6 Mar 2008 12:16:49 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6DDC3A6E13; Thu, 6 Mar 2008 12:16:49 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9435A3A6DB1 for ; Thu, 6 Mar 2008 12:16:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEYHcvl8bhbv for ; Thu, 6 Mar 2008 12:16:44 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 3E9903A6DF4 for ; Thu, 6 Mar 2008 12:16:44 -0800 (PST) Received: (qmail invoked by alias); 06 Mar 2008 20:16:32 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp020) with SMTP; 06 Mar 2008 21:16:32 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+Baa0yfwOBBYgAUxoXA3zLu1vhHPfTkjLWLLjh28 Ozf7Ig+L7gLbAm Message-ID: <47D0511F.4010408@gmx.net> Date: Thu, 06 Mar 2008 22:16:31 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 Cc: mrbrenner@alcatel-lucent.com Subject: [Dime] [Fwd: Document Action: 'Diameter Policy Processing Application' to Informational RFC] X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Thanks to Dan and Michael for the work. -------- Original Message -------- Subject: Document Action: 'Diameter Policy Processing Application' to Informational RFC Date: Thu, 6 Mar 2008 12:10:57 -0800 (PST) From: The IESG To: IETF-Announce CC: Internet Architecture Board , RFC Editor The IESG has approved the following document: - 'Diameter Policy Processing Application ' as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Dan Romascanu. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brenner-dime-peem-01.txt Technical Summary This document describes the need for a new IANA Diameter Command Code to be used in a vendor-specific new application for invocation of Policy Processing (Policy Evaluation, or Evaluation and Enforcement). This application is needed as one of the implementations of the Open Mobile Aliance (OMA) Policy Evaluation, Enforcement and Management (PEEM) enabler, namely for the PEM-1 interface used to send a request/responses for Policy Processing. Working Group Summary This is an Area Director sponsored individual submission, which was written following a discussion in the IESG about the best way to support the allocation of the command code required by the OMA. Document Quality The original document that defines the new application was discussed and approved by the OMA. Personnel The sponsoring Area Director was Dan Romascanu. Hannes Tschofenig reviewed the document on behalf of the Diameter Extensions (DIME) WG. The document was also reviewed by IANA. RFC Editor Note Please make the following change: OLD: 5.1. Command Codes This specification assigns the value TBD-Cmd-code from the Command Code namespace defined in [RFC3588]. See Section 5.4.1.3.1 of [PEM-1-TS] for the assignment of the TBD-Cmd-code. 5.2. AVP Codes This specification assigns the value TBD-AVP-Code for the Policy-Data AVP, in the OMA Vendor-ID (PEN) AVP namespace. See Section 5.4.1.3.3 of [PEM-1-TS] for the assignment of the namespace in this specification. 5.3. Application Identifier This specification uses the value 16777243 in the Application Identifier namespace as registered in IANA for the Policy Processing Application. See Section 5.4.1.3 of [PEM-1-TS] for more information. NEW: 5.1. Command Codes This specification assigns the value TBD-Cmd-code from the Command Code namespace defined in [RFC3588]. See Section 5.4.1.3.1 of [PEM-1-TS] for the assignment of the TBD-Cmd-code. Upon approval of this document, the IANA will make the following assignments in the "Authentication, Authorization, and Accounting (AAA) Parameters" registry located at http://www.iana.org/assignments/aaa-parameters sub-registry "Command Codes" Code Value Name Reference -------------- ------------------------------- --------- [TBD-Cmd-code] PDR / PDA [RFC-brenner-dime-peem-01] 5.2. AVP Codes This specification uses the value 1 for the Policy-Data AVP, in the OMA Vendor-ID (PEN) AVP namespace. See Section 5.4.1.3.3 of [PEM-1-TS] for the assignment of the namespace in this specification. No IANA Action is required. 5.3. Application Identifier This specification uses the value 16777243 in the Application Identifier namespace as registered in IANA for the Policy Processing Application. See Section 5.4.1.3 of [PEM-1-TS] for more information. No IANA action is required. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Mar 7 09:55:11 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 182C528CA18; Fri, 7 Mar 2008 09:55:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.352 X-Spam-Level: X-Spam-Status: No, score=-100.352 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDjqxwBMzzYj; Fri, 7 Mar 2008 09:55:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D14628C2E1; Fri, 7 Mar 2008 09:55:09 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D1A928C9B2 for ; Fri, 7 Mar 2008 09:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Bclg5MbfnOx for ; Fri, 7 Mar 2008 09:55:01 -0800 (PST) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 6176528C333 for ; Fri, 7 Mar 2008 09:55:01 -0800 (PST) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA05.westchester.pa.mail.comcast.net with comcast id yFfD1Y03U1GhbT85504K00; Fri, 07 Mar 2008 17:53:58 +0000 Received: from [192.168.1.120] ([69.255.66.123]) by OMTA07.westchester.pa.mail.comcast.net with comcast id yHum1Y0092fa1BZ3T00000; Fri, 07 Mar 2008 17:54:47 +0000 X-Authority-Analysis: v=1.0 c=1 a=jiV82iFEX0Ru32177tkA:9 a=QDO9ycTJraVqsBOQFcgoKSnIdNYA:4 a=M3PvEdNFSBYA:10 Message-Id: From: ken carlberg To: Gerald Ash In-Reply-To: <940378.320.qm@web63606.mail.re1.yahoo.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 7 Mar 2008 12:54:46 -0500 References: <940378.320.qm@web63606.mail.re1.yahoo.com> X-Mailer: Apple Mail (2.919.2) Cc: dime@ietf.org, tsvwg , NSIS Subject: Re: [Dime] [NSIS] WG last call on draft-ietf-tsvwg-emergency-rsvp-05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org > Let me make sure I have this straight. In the NSIS discussion you > insist that we change the name to in > order to resolve the debate, while the NSIS admission priority > approach is in fact as implemented today for ETS and has little to > do with Y.2171 other than to populate the initial admission priority > values in the registry. OTOH, the rsvp admission priority approach > uses a specific rsvp object, is populated from an rsvp-specific p- > type, and AFAIK is not implemented anywhere as yet. Yet this rsvp- > specific admission priority approach is now declared the 'generic' > admission priority mechanism? yes > Hopefully you'll also respond to my comments 2 & 4: I'm not speaking for Francois, but I would ask that if you are pointingly asking for responses, then please display the same courtesy and respond to at the questions sent to you previously on this thread. if you choose not to, fine, but let's not make this one way street. > 2. Presumably the emergency-rsvp admission priority approach is > implemented (or planned to be implemented) in real network > applications. It would be nice to reference such implementations, > existing or planned, if possible. implementations and deployments in the context you speak of are a rat hole. I'm under several non-disclosure agreements on this general topic, and I can imagine that Francois is under similar constraints with respect to his customers. You should be aware of this kind of bind. But, if you are not under the same constraints, I'd be happy to openly hear of specific vendor/operator deployments you are aware of. Otherwise, let's drop this specific sub-thread. > 4. Section 3.1 (Admission Priority Policy Element) of emergency-rsvp > states: > > "Adm. Priority (Admission Priority): 8 bits (unsigned) > The admission control priority of the flow, in terms of access to > network bandwidth in order to provide higher probability of call > completion to selected flows. Higher values represent higher > Priority. A given Admission Priority is encoded in this information > element using the same value as when encoded in the Admission > Priority parameter defined in section 6.2.9 of [NSIS-QSPEC], or in > the Admission Priority parameter defined in section 4.10 of [DIME- > PARAM]. In other words, a given value inside the Admission Priority > information element defined in the present document, inside the > [NSIS-QSPEC] Admission Priority parameter or inside the [DIME- > PARAM] > Admission Priority parameter, refers to the same Admission > Priority." > > The text is very unclear as to what it means that admission priority > values are encoded 'using the same value' in the 3 different > drafts? Perhaps an example would help, but in any case it should be > clarified. Further, the text should be updated to note that the > field is not directly comparable to the 2171 Admission Priority> field in the qspec draft so as to avoid > confusion. The above cited text clearly needs to be re-written depending on the outcome of this thread, so attempts at altering the it before any NEW consensus is agreed on premature at this point. -ken _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Mar 8 06:17:32 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 379C628CFB1; Sat, 8 Mar 2008 06:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.518 X-Spam-Level: X-Spam-Status: No, score=-101.518 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zznkJlEkOtF9; Sat, 8 Mar 2008 06:17:31 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48F7328E7A2; Sat, 8 Mar 2008 05:41:11 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A906F28D890 for ; Sat, 8 Mar 2008 05:41:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRHegOZ7Vpe9 for ; Sat, 8 Mar 2008 05:41:07 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 737C52941B1 for ; Fri, 7 Mar 2008 19:02:12 -0800 (PST) Received: (qmail invoked by alias); 08 Mar 2008 03:01:59 -0000 Received: from 12-198-48-130att-inc.com (EHLO [172.28.172.47]) [12.198.48.130] by mail.gmx.net (mp023) with SMTP; 08 Mar 2008 04:01:59 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19Arl5x8vZA9k/t/nmQtRChmmb7+CHqF6FN9GYFyT 01/qJzM1RWIXwM Message-ID: <47D20198.4040106@gmx.net> Date: Sat, 08 Mar 2008 05:01:44 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 Subject: [Dime] Slides X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Please sent your slides to Victor so that he can upload them to the webpage. Thanks _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Mar 10 08:19:37 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DE6A28DCB3; Mon, 10 Mar 2008 08:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.328 X-Spam-Level: X-Spam-Status: No, score=-100.328 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sed9x1LB18ZA; Mon, 10 Mar 2008 08:19:36 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D8CD28E255; Mon, 10 Mar 2008 08:00:30 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DC9D28E1DB for ; Mon, 10 Mar 2008 08:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYou53Zc++TY for ; Mon, 10 Mar 2008 08:00:26 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 95F1A293BA2 for ; Mon, 10 Mar 2008 06:27:57 -0700 (PDT) Received: (qmail invoked by alias); 10 Mar 2008 13:25:35 -0000 Received: from dhcp-160b.ietf71.ietf.org (EHLO [130.129.22.11]) [130.129.22.11] by mail.gmx.net (mp021) with SMTP; 10 Mar 2008 14:25:35 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18WGFl5OuwWSAoEdMuHeKd/+xAsSX7ikf8Af6v+hR PmbRr2+WT4H9iS Message-ID: <47D536D1.2080608@gmx.net> Date: Mon, 10 Mar 2008 15:25:37 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: GEOPRIV , dime@ietf.org X-Y-GMX-Trusted: 0 Subject: [Dime] FW: Location-Data AVP in a2 Diameter X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org RllJCgogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiAgICAqRnJvbToqIFRpbmEgVFNPVSBbbWFpbHRvOnRl bmFAaHVhd2VpLmNvbV0KICAgICpTZW50OiogTWFyY2ggNywgMjAwOCAwOToyMwogICAgKlRvOiog VElTUEFOX1dHM0BMSVNULkVUU0kuT1JHOyBTb25pYSBDb21wYW5zCiAgICAqQ2M6KiBiZXJuYXJk YUBtaWNyb3NvZnQuY29tOyBBdmkgTGlvcjsgTWFyayBKb25lczsKICAgIGZhcmlkLmFkcmFuZ2lA aW50ZWwuY29tOyBoYW5uZXMudHNjaG9mZW5pZ0Buc24uY29tCiAgICAqU3ViamVjdDoqIFJlOiBM b2NhdGlvbi1EYXRhIEFWUCBpbiBhMiBEaWFtZXRlcgoKICAgIE1lcmNpLCBCcnVubyBhbmQgU29u aWEuCiAgICBUaGVuIHRoZSBMb2NhdGlvbi1EYXRhIEFWUCBpbiBhMiBEaWFtZXRlciBpcyBhbGxv Y2F0ZWQgYXMgNjA0IDEzMDE5CiAgICBieSBFVFNJLCBhcyBpdCBzZWVtcyB0aGF0IGl0IHdpbGwg YmUgYmVmb3JlCiAgICBkcmFmdC1pZXRmLWdlb3ByaXYtcmFkaXVzLWxvLTE5IGlzIGNvbnZlcnRl ZCB0byBhbiBSRkMuCiAgICBJIGNvcHkgdG8gdGhlIGF1dGhvcnMgb2YgZHJhZnQtaWV0Zi1nZW9w cml2LXJhZGl1cy1sby0xOSBmb3IgdGhlaXIKICAgIGluZm9ybWF0aW9uLgogICAgSSBob3BlIHRo aXMgYXBwcm9hY2ggd2lsbCBub3QgY2F1c2UgcHJvYmxlbS4KICAgICAKICAgIEkgdXBkYXRlIGl0 LCBhbmQgdXBsb2FkIHRoZSBvdXRwdXQgYXMgMTZiVEQ0NDZyMy4KICAgICAKICAgIEIuIFIuCiAg ICBUaW5hCgogICAgICAgIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KICAgICAgICAqRnJv bToqIFNvbmlhIENvbXBhbnMgPG1haWx0bzpTb25pYS5Db21wYW5zQEVUU0kuT1JHPgogICAgICAg ICpUbzoqIFRJU1BBTl9XRzNATElTVC5FVFNJLk9SRyA8bWFpbHRvOlRJU1BBTl9XRzNATElTVC5F VFNJLk9SRz4KICAgICAgICAqU2VudDoqIEZyaWRheSwgTWFyY2ggMDcsIDIwMDggMTA6NDIgQU0K ICAgICAgICAqU3ViamVjdDoqIFJlOiBMb2NhdGlvbi1EYXRhIEFWUCBpbiBhMiBEaWFtZXRlcgoK ICAgICAgICBEZWFyIGFsbCwKICAgICAgICAgCiAgICAgICAgRVRTSSBjYW4gYWxsb2NhdGUgdGhl IEFWUCBjb2RlIGlmICBpdCBpcyBwYXJ0IG9mIHRoZSBBVlBzCiAgICAgICAgZGVmaW5lZCBpbiB0 aGUgYTIgc3BlY2lmaWNhdGlvbi4gVGhpcyBtZWFucyB0aGF0IHRoaXMgQVZQIG5lZWRzCiAgICAg ICAgdG8gYmUgdHJhbnNmZXJlZCB0byB0YWJsZSA3LjEgYW5kIGFzc29jaWF0ZWQgd2l0aCB0aGUg RVRTSQogICAgICAgIFZlbmRvci1JZCBhbmQgYW55IHJlZmVyZW5jZSB0byB0aGUgZHJhZnQgaWV0 ZiBpcyByZW1vdmVkLgogICAgICAgICAKICAgICAgICBBcyBUaW5hIGtub3dzLCB0aGUgRVRTSSBB VlAgcmFuZ2UgaGFzIGFscmVhZHkgYmVlbiBhbGxvY2F0ZWQgYnkKICAgICAgICBFVFNJLiBJZiB5 b3UgZGVjaWRlIHRvIGdvIGZvciBhbiBFVFNJIGFsbG9jYXRpb24sIHRoZW4gVGluYSBjYW4KICAg ICAgICB1c2UgdGhlIG5leHQgYXZhaWxhYmxlIEFWUCBjb2RlLgogICAgICAgICAKICAgICAgICBC eSB0aGUgd2F5LCBUaW5hLCB5b3UgbmVlZCB0byB1cGRhdGUgdGFibGUgNy4xIHdpdGggdGhlCiAg ICAgICAgYWxsb2NhdGVkIEFWUCB2YWx1ZXMgKHRoZXkgYXJlIHN0aWxsIHNldCB0byAnVEJEJyku CiAgICAgICAgIAogICAgICAgIEJlc3QgcmVnYXJkcwogICAgICAgIFNvbmlhCgogICAgICAgIC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQogICAgICAgICpGcm9tOiogQnJ1bm8gQ2hhdHJhcyBbbWFpbHRvOmJydW5v LmNoYXRyYXNAT1JBTkdFLUZUR1JPVVAuQ09NXQogICAgICAgICpTZW50OiogMDYgTWFyY2ggMjAw OCAxODo0MQogICAgICAgICpUbzoqIFRJU1BBTl9XRzMKICAgICAgICAqU3ViamVjdDoqIFJlOiBb VElTUEFOX1dHM10gTG9jYXRpb24tRGF0YSBBVlAgaW4gYTIgRGlhbWV0ZXIKCiAgICAgICAgSSBk b24ndCB0aGluayB3ZSBuZWVkIElBTkEgZm9yIHRoYXQuIFRoZXNlIGNvZGVzIGNhbiBiZQogICAg ICAgIGFsbG9jYXRlZCBieSBFVFNJLiBXZSBoYXZlIHRvIHJlcXVlc3QgUFRDQyBmb3IgYSBibG9j ayBvZiBBVlAKICAgICAgICBjb2RlcyBmb3IgdGhlIGEyIHNwZWNpZmljYXRpb24gYXMgd2UgZGlk IGZvciBlMixlNCxHcScuLi4KICAgICAgICAgCiAgICAgICAgIkVUU0kgUFRDQyBtYW5hZ2VzIHRo ZSBhbGxvY2F0aW9uIG9mIEVUU0kgQVZQIGNvZGVzLCBBVlAKICAgICAgICBzcGVjaWZpYyB2YWx1 ZXMgYW5kIEV4cGVyaW1lbnRhbCBSZXN1bHQgQ29kZXMuIAogICAgICAgIEVUU0kgZ2VuZXJhbGx5 IGFsbG9jYXRlcyBhIGJsb2NrIG9mIDUwIEFWUCBjb2RlcyB0byBlYWNoCiAgICAgICAgc3BlY2lm aWNhdGlvbiBpbiB3aGljaCBEaWFtZXRlciBBVlAgY29kZXMgYXJlIHNwZWNpZmllZCwgYW5kIGEK ICAgICAgICBibG9jayBvZiAyMCBFeHBlcmltZW50YWwgUmVzdWx0IENvZGVzIHRvIGVhY2ggc3Bl Y2lmaWNhdGlvbiBpbgogICAgICAgIHdoaWNoIHRoZXNlIGNvZGVzIGFyZSBzcGVjaWZpZWQuICBB bGxvY2F0aW9uIGlzIHBlcmZvcm1lZCBvbiBhCiAgICAgICAgZmlyc3QtY29tZSwgZmlyc3Qtc2Vy dmVkIGJhc2lzLiIKICAgICAgICAgCiAgICAgICAgaHR0cDovL3BvcnRhbC5ldHNpLm9yZy9wdGNj L2RpYW1ldGVybnVtYmVycy5hc3AKCiAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiAgICAgICAgKkRl IDoqIFRpbmEgVFNPVSBbbWFpbHRvOnRlbmFASFVBV0VJLkNPTV0KICAgICAgICAqRW52b3nDqSA6 KiBqZXVkaSA2IG1hcnMgMjAwOCAxODoxMgogICAgICAgICrDgCA6KiBUSVNQQU5fV0czQExJU1Qu RVRTSS5PUkcKICAgICAgICAqT2JqZXQgOiogTG9jYXRpb24tRGF0YSBBVlAgaW4gYTIgRGlhbWV0 ZXIKCiAgICAgICAgRGVhciBhbGwsCiAgICAgICAgUmVnYXJkaW5nIExvY2F0aW9uLURhdGEgQVZQ IGluIGEyIERpYW1ldGVyLCBJIGFtIG5vdCBhYmxlIHRvCiAgICAgICAgZmlsbCBBVlAgY29kZSBm b3IgaXQuIFVudGlsIGl0IGlzIGNvbnZlcnRlZCB0byBhbiBSRkMgdGhlIEFWUAogICAgICAgIG51 bWJlcnMgd29uJ3QgYmUgYXNzaWduZWQgYnkgSUFOQS4KICAgICAgICAgCgogICAgICAgICAKCiAg ICAgICAgKlRhYmxlICoqNy40Kio6IERpYW1ldGVyIEFWUHMgZGVmaW5lZCBpbiBJRVRGIHNwZWNp ZmljYXRpb25zKgoKICAgICAgICAgKioKCiAgICAgICAgCQoKICAgICAgICAqQVZQIEZsYWcgcnVs ZXMqCgogICAgICAgIAkKCiAgICAgICAgICoqCgogICAgICAgICpBdHRyaWJ1dGUgTmFtZSoKCiAg ICAgICAgCQoKICAgICAgICAqQVZQIENvZGUqCgogICAgICAgIAkKCiAgICAgICAgKkNsYXVzZSBk ZWZpbmVkKgoKICAgICAgICAJCgogICAgICAgICpWYWx1ZSBUeXBlKgoKICAgICAgICAJCgogICAg ICAgICpNdXN0KgoKICAgICAgICAJCgogICAgICAgICpNYXkqCgogICAgICAgIAkKCiAgICAgICAg KlNob3VsZCBub3QqCgogICAgICAgIAkKCiAgICAgICAgKk11c3Qgbm90KgoKICAgICAgICAJCgog ICAgICAgICpNYXkgRW5jcnlwdCoKCiAgICAgICAgTG9jYXRpb24tRGF0YQoKICAgICAgICAJCgog ICAgICAgIFRCRAoKICAgICAgICAJCgogICAgICAgIFs4IDxtaHRtbDptaWQ6Ly8wMDAwMDQzNC8j dGluYTg+XQoKICAgICAgICAJCgogICAgICAgIE9jdGV0U3RyaW5nCgogICAgICAgIAkKCiAgICAg ICAgIAoKICAgICAgICAJCgogICAgICAgIE0KCiAgICAgICAgCQoKICAgICAgICAgCgogICAgICAg IAkKCiAgICAgICAgVgoKICAgICAgICAJCgogICAgICAgIE5vCgogICAgICAgIE5PVEU6ICAgICAg IFRoZSBBVlAgaGVhZGVyIGJpdCBkZW5vdGVkIGFzICJNIiwgaW5kaWNhdGVzIHdoZXRoZXIKICAg ICAgICBzdXBwb3J0IG9mIHRoZSBBVlAgaXMgcmVxdWlyZWQuIFRoZSBBVlAgaGVhZGVyIGJpdCBk ZW5vdGVkIGFzCiAgICAgICAgIlYiLCBpbmRpY2F0ZXMgd2hldGhlciB0aGUgb3B0aW9uYWwgVmVu ZG9y4oCRSUQgZmllbGQgaXMgcHJlc2VudAogICAgICAgIGluIHRoZSBBVlAgaGVhZGVyLgoKICAg ICAgICAgCgoKICAgICAgICAgICAgICA3LjMuOCAgTG9jYXRpb24tRGF0YSBBVlAKCiAgICAgICAg VGhlIExvY2F0aW9uLURhdGEgQVZQIGlzIGRlZmluZWQgaW4KICAgICAgICBkcmFmdC1pZXRmLWdl b3ByaXYtcmFkaXVzLWxvLTE2IFs4CiAgICAgICAgPG1odG1sOm1pZDovLzAwMDAwNDM0LyN0aW5h OD5dLiBJdCBjb250YWlucyBsb2NhdGlvbiBkYXRhIGluIHRoZQogICAgICAgIGZvcm0gb2YgZWl0 aGVyIENpdmljIExvY2F0aW9uIG9yIEdlb3NwYXRpYWwgTG9jYXRpb24uCgogICAgICAgICAKCiAg ICAgICAgIAogICAgICAgICAKICAgICAgICBCLiBSLgogICAgICAgIFRpbmEKICAgICAgICBNZXNz ZW5nZXJzOgogICAgICAgIE1TTjogdGluYXRzb3U2QGhvdG1haWwuY29tIDxtYWlsdG86dGluYXRz b3U2QGhvdG1haWwuY29tPiAgCiAgICAgICAgWWFob286IHRpbmFfdHNvdSAgICBTa3lwZTogdGlu YVRTT1UgICAgSmFiYmVyOiB0aW5hQGphYmJlci5vcmcKICAgICAgICA8bWFpbHRvOnRpbmFAamFi YmVyLm9yZz4gICAgR29vZ2xlIHRhbGs6IHRpbmF0c291NkBnbWFpbC5jb20KICAgICAgICA8bWFp bHRvOnRpbmF0c291NkBnbWFpbC5jb20+CiAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCgogICAgICAg IE1haWwgYXJjaGl2ZSBmb3IgVElTUEFOX1dHMyBjYW4gYmUgYnJvd3NlZCBhdCB0aGUgZm9sbG93 aW5nIHVybCA6CgogICAgICAgIGh0dHA6Ly9saXN0LmV0c2kub3JnL1RJU1BBTl9XRzMuaHRtbAoK ICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCkRpTUUgbWFpbGluZyBsaXN0CkRpTUVAaWV0Zi5vcmcKaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lCg== From dime-bounces@ietf.org Tue Mar 11 02:58:58 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 922A228C34E; Tue, 11 Mar 2008 02:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.518 X-Spam-Level: X-Spam-Status: No, score=-101.518 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXWMnEniAz6o; Tue, 11 Mar 2008 02:58:57 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81A4E28C349; Tue, 11 Mar 2008 02:58:57 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2052628C33A; Tue, 11 Mar 2008 02:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBss3eM3cDjK; Tue, 11 Mar 2008 02:58:55 -0700 (PDT) Received: from s-utl01-dcpop.stsn.net (s-utl01-dcpop.stsn.net [72.255.0.201]) by core3.amsl.com (Postfix) with SMTP id 720AA28C337; Tue, 11 Mar 2008 02:58:55 -0700 (PDT) Received: from s-utl01-dcpop.stsn.net ([127.0.0.1]) by s-utl01-dcpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2008031105563423660 ; Tue, 11 Mar 2008 05:56:34 -0400 Received: from jys3105121962 ([10.150.134.65]) by s-utl01-dcpop.stsn.net; Tue, 11 Mar 2008 05:56:33 -0400 Message-ID: <021801c8835e$2f451480$4a96a8c0@jys3105121962> From: "Tina TSOU" To: , "GEOPRIV" , "Hannes Tschofenig" References: <47D536D1.2080608@gmx.net> Date: Tue, 11 Mar 2008 05:56:21 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Dime] FW: Location-Data AVP in a2 Diameter X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Ci0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gCkZyb206IFRpbmEgVFNPVQpUbzogVElTUEFO X1dHM0BMSVNULkVUU0kuT1JHIDsgYnJ1bm8uY2hhdHJhc0BPUkFOR0UtRlRHUk9VUC5DT00KQ2M6 IGhhbm5lcy50c2Nob2ZlbmlnQG5zbi5jb20gOyBmYXJpZC5hZHJhbmdpQGludGVsLmNvbSA7IApt YXJrLmpvbmVzQGJyaWRnZXdhdGVyc3lzdGVtcy5jb20gOyBBdmkgTGlvciA7IGJlcm5hcmRhQG1p Y3Jvc29mdC5jb20gOyAKSGFubmVzIFRzY2hvZmVuaWcKU2VudDogVHVlc2RheSwgTWFyY2ggMTEs IDIwMDggNTo1NCBBTQpTdWJqZWN0OiBSZTogTG9jYXRpb24tRGF0YSBBVlAgaW4gYTIgRGlhbWV0 ZXIKCgpCcnVubywKTWVyY2ksIHRoYXQncyB3aGF0IEkgbWVhbnQ6KQpZZXMsIEkgZGlzY3Vzc2Vk IHdpdGggQXZpIGFuZCBNYXJrIGluIFBoaWxseSB5ZXN0ZXJkYXkuIFRoZXkgYXJlIGRvaW5nIGl0 LgoKCkIuIFIuClRpbmEKTWVzc2VuZ2VyczoKTVNOOiB0aW5hdHNvdTZAaG90bWFpbC5jb20gICBZ YWhvbzogdGluYV90c291ICAgIFNreXBlOiB0aW5hVFNPVSAgICBKYWJiZXI6IAp0aW5hQGphYmJl ci5vcmcgICAgR29vZ2xlIHRhbGs6IHRpbmF0c291NkBnbWFpbC5jb20KICAtLS0tLSBPcmlnaW5h bCBNZXNzYWdlIC0tLS0tIAogIEZyb206IEJydW5vIENoYXRyYXMKICBUbzogVElTUEFOX1dHM0BM SVNULkVUU0kuT1JHCiAgU2VudDogTW9uZGF5LCBNYXJjaCAxMCwgMjAwOCAxMjowNCBQTQogIFN1 YmplY3Q6IFJlOiBMb2NhdGlvbi1EYXRhIEFWUCBpbiBhMiBEaWFtZXRlcgoKCiAgVGluYSwKCiAg V2hlbiBJIGFuc3dlcmVkIHRoZSBmaXJzdCBtZXNzYWdlIEkgZGlkIG5vdCByZWFsaXNlIHRoYXQg eW91IHdlcmUgCnJlZmVycmluZyBzcGVjaWZpY2FsbHkgdG8gdGhlIExvY2F0aW9uLURhdGEgQVZQ LiBJIHRob3VnaHQgeW91IHdlcmUgCnJlZmVycmluZyB0byB0aGUgbmV3IEFWUHMgZGVmaW5lZCBp bnNpZGUgdGhlIGEyIHNwZWNpZmljYXRpb24gKEFDUy1zZXJ2ZXIsIApURlRQLXNlcnZlciwgZXRj Li4uKS4gRm9yIHRoZSBMb2NhdGlvbi1EYXRhIEFWUCB3ZSBhcmUgaW5kZWVkIGRlcGVuZGVudCBv biAKdGhlIHByb2dyZXNzIG9mIHRoZSBJRVRGIEludGVybmV0LURyYWZ0LiBJIGJlbGlldmUgd2Ug c2hvdWxkIG5vdCBhbGxvY2F0ZSBhbiAKRVRTSSBjb2RlIHRvIHRoaXMgcGFydGljdWxhciBvbmUg YnV0IHJhdGhlciB3YWl0IGZvciB0aGUgSUVURiByZXF1ZXN0aW5nIG9uZSAKZnJvbSBJQU5BLiBD b3VsZCB5b3UgY2hlY2sgd2l0aCB0aGUgYXV0aG9ycyBvZiB0aGUgSW50ZXJuZXQtRHJhZnQgd2hl dGhlciBpdCAKaXMgcG9zc2libGUgZm9yIHRoZW0gdG8gcmVxdWVzdCB0aGlzIEFWUCBjb2RlIGJl Zm9yZSB0aGUgSW50ZXJuZXQtRHJhZnQgCmJlY29tZXMgYW4gUkZDLgoKICBTb3JyeSBmb3IgaGF2 aW5nIGJyb3VnaHQgY29uZnVzaW9uIGludG8gdGhlIGRlYmF0ZS4uLgoKICBCcnVubwoKCi0tLS0t IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gCkZyb206ICJIYW5uZXMgVHNjaG9mZW5pZyIgPEhhbm5l cy5Uc2Nob2ZlbmlnQGdteC5uZXQ+ClRvOiAiR0VPUFJJViIgPGdlb3ByaXZAaWV0Zi5vcmc+OyA8 ZGltZUBpZXRmLm9yZz4KU2VudDogTW9uZGF5LCBNYXJjaCAxMCwgMjAwOCA5OjI1IEFNClN1Ympl Y3Q6IFtEaW1lXSBGVzogTG9jYXRpb24tRGF0YSBBVlAgaW4gYTIgRGlhbWV0ZXIKCgo+IEZZSQo+ Cj4gICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gICAgKkZyb206KiBUaW5hIFRTT1UgW21haWx0bzp0ZW5h QGh1YXdlaS5jb21dCj4gICAgKlNlbnQ6KiBNYXJjaCA3LCAyMDA4IDA5OjIzCj4gICAgKlRvOiog VElTUEFOX1dHM0BMSVNULkVUU0kuT1JHOyBTb25pYSBDb21wYW5zCj4gICAgKkNjOiogYmVybmFy ZGFAbWljcm9zb2Z0LmNvbTsgQXZpIExpb3I7IE1hcmsgSm9uZXM7Cj4gICAgZmFyaWQuYWRyYW5n aUBpbnRlbC5jb207IGhhbm5lcy50c2Nob2ZlbmlnQG5zbi5jb20KPiAgICAqU3ViamVjdDoqIFJl OiBMb2NhdGlvbi1EYXRhIEFWUCBpbiBhMiBEaWFtZXRlcgo+Cj4gICAgTWVyY2ksIEJydW5vIGFu ZCBTb25pYS4KPiAgICBUaGVuIHRoZSBMb2NhdGlvbi1EYXRhIEFWUCBpbiBhMiBEaWFtZXRlciBp cyBhbGxvY2F0ZWQgYXMgNjA0IDEzMDE5Cj4gICAgYnkgRVRTSSwgYXMgaXQgc2VlbXMgdGhhdCBp dCB3aWxsIGJlIGJlZm9yZQo+ICAgIGRyYWZ0LWlldGYtZ2VvcHJpdi1yYWRpdXMtbG8tMTkgaXMg Y29udmVydGVkIHRvIGFuIFJGQy4KPiAgICBJIGNvcHkgdG8gdGhlIGF1dGhvcnMgb2YgZHJhZnQt aWV0Zi1nZW9wcml2LXJhZGl1cy1sby0xOSBmb3IgdGhlaXIKPiAgICBpbmZvcm1hdGlvbi4KPiAg ICBJIGhvcGUgdGhpcyBhcHByb2FjaCB3aWxsIG5vdCBjYXVzZSBwcm9ibGVtLgo+Cj4gICAgSSB1 cGRhdGUgaXQsIGFuZCB1cGxvYWQgdGhlIG91dHB1dCBhcyAxNmJURDQ0NnIzLgo+Cj4gICAgQi4g Ui4KPiAgICBUaW5hCj4KPiAgICAgICAgLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo+ICAg ICAgICAqRnJvbToqIFNvbmlhIENvbXBhbnMgPG1haWx0bzpTb25pYS5Db21wYW5zQEVUU0kuT1JH Pgo+ICAgICAgICAqVG86KiBUSVNQQU5fV0czQExJU1QuRVRTSS5PUkcgPG1haWx0bzpUSVNQQU5f V0czQExJU1QuRVRTSS5PUkc+Cj4gICAgICAgICpTZW50OiogRnJpZGF5LCBNYXJjaCAwNywgMjAw OCAxMDo0MiBBTQo+ICAgICAgICAqU3ViamVjdDoqIFJlOiBMb2NhdGlvbi1EYXRhIEFWUCBpbiBh MiBEaWFtZXRlcgo+Cj4gICAgICAgIERlYXIgYWxsLAo+Cj4gICAgICAgIEVUU0kgY2FuIGFsbG9j YXRlIHRoZSBBVlAgY29kZSBpZiAgaXQgaXMgcGFydCBvZiB0aGUgQVZQcwo+ICAgICAgICBkZWZp bmVkIGluIHRoZSBhMiBzcGVjaWZpY2F0aW9uLiBUaGlzIG1lYW5zIHRoYXQgdGhpcyBBVlAgbmVl ZHMKPiAgICAgICAgdG8gYmUgdHJhbnNmZXJlZCB0byB0YWJsZSA3LjEgYW5kIGFzc29jaWF0ZWQg d2l0aCB0aGUgRVRTSQo+ICAgICAgICBWZW5kb3ItSWQgYW5kIGFueSByZWZlcmVuY2UgdG8gdGhl IGRyYWZ0IGlldGYgaXMgcmVtb3ZlZC4KPgo+ICAgICAgICBBcyBUaW5hIGtub3dzLCB0aGUgRVRT SSBBVlAgcmFuZ2UgaGFzIGFscmVhZHkgYmVlbiBhbGxvY2F0ZWQgYnkKPiAgICAgICAgRVRTSS4g SWYgeW91IGRlY2lkZSB0byBnbyBmb3IgYW4gRVRTSSBhbGxvY2F0aW9uLCB0aGVuIFRpbmEgY2Fu Cj4gICAgICAgIHVzZSB0aGUgbmV4dCBhdmFpbGFibGUgQVZQIGNvZGUuCj4KPiAgICAgICAgQnkg dGhlIHdheSwgVGluYSwgeW91IG5lZWQgdG8gdXBkYXRlIHRhYmxlIDcuMSB3aXRoIHRoZQo+ICAg ICAgICBhbGxvY2F0ZWQgQVZQIHZhbHVlcyAodGhleSBhcmUgc3RpbGwgc2V0IHRvICdUQkQnKS4K Pgo+ICAgICAgICBCZXN0IHJlZ2FyZHMKPiAgICAgICAgU29uaWEKPgo+ICAgICAgICAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0KPiAgICAgICAgKkZyb206KiBCcnVubyBDaGF0cmFzIFttYWlsdG86YnJ1bm8uY2hh dHJhc0BPUkFOR0UtRlRHUk9VUC5DT01dCj4gICAgICAgICpTZW50OiogMDYgTWFyY2ggMjAwOCAx ODo0MQo+ICAgICAgICAqVG86KiBUSVNQQU5fV0czCj4gICAgICAgICpTdWJqZWN0OiogUmU6IFtU SVNQQU5fV0czXSBMb2NhdGlvbi1EYXRhIEFWUCBpbiBhMiBEaWFtZXRlcgo+Cj4gICAgICAgIEkg ZG9uJ3QgdGhpbmsgd2UgbmVlZCBJQU5BIGZvciB0aGF0LiBUaGVzZSBjb2RlcyBjYW4gYmUKPiAg ICAgICAgYWxsb2NhdGVkIGJ5IEVUU0kuIFdlIGhhdmUgdG8gcmVxdWVzdCBQVENDIGZvciBhIGJs b2NrIG9mIEFWUAo+ICAgICAgICBjb2RlcyBmb3IgdGhlIGEyIHNwZWNpZmljYXRpb24gYXMgd2Ug ZGlkIGZvciBlMixlNCxHcScuLi4KPgo+ICAgICAgICAiRVRTSSBQVENDIG1hbmFnZXMgdGhlIGFs bG9jYXRpb24gb2YgRVRTSSBBVlAgY29kZXMsIEFWUAo+ICAgICAgICBzcGVjaWZpYyB2YWx1ZXMg YW5kIEV4cGVyaW1lbnRhbCBSZXN1bHQgQ29kZXMuCj4gICAgICAgIEVUU0kgZ2VuZXJhbGx5IGFs bG9jYXRlcyBhIGJsb2NrIG9mIDUwIEFWUCBjb2RlcyB0byBlYWNoCj4gICAgICAgIHNwZWNpZmlj YXRpb24gaW4gd2hpY2ggRGlhbWV0ZXIgQVZQIGNvZGVzIGFyZSBzcGVjaWZpZWQsIGFuZCBhCj4g ICAgICAgIGJsb2NrIG9mIDIwIEV4cGVyaW1lbnRhbCBSZXN1bHQgQ29kZXMgdG8gZWFjaCBzcGVj aWZpY2F0aW9uIGluCj4gICAgICAgIHdoaWNoIHRoZXNlIGNvZGVzIGFyZSBzcGVjaWZpZWQuICBB bGxvY2F0aW9uIGlzIHBlcmZvcm1lZCBvbiBhCj4gICAgICAgIGZpcnN0LWNvbWUsIGZpcnN0LXNl cnZlZCBiYXNpcy4iCj4KPiAgICAgICAgaHR0cDovL3BvcnRhbC5ldHNpLm9yZy9wdGNjL2RpYW1l dGVybnVtYmVycy5hc3AKPgo+ICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiAgICAgICAgKkRlIDoq IFRpbmEgVFNPVSBbbWFpbHRvOnRlbmFASFVBV0VJLkNPTV0KPiAgICAgICAgKkVudm95w6kgOiog amV1ZGkgNiBtYXJzIDIwMDggMTg6MTIKPiAgICAgICAgKsOAIDoqIFRJU1BBTl9XRzNATElTVC5F VFNJLk9SRwo+ICAgICAgICAqT2JqZXQgOiogTG9jYXRpb24tRGF0YSBBVlAgaW4gYTIgRGlhbWV0 ZXIKPgo+ICAgICAgICBEZWFyIGFsbCwKPiAgICAgICAgUmVnYXJkaW5nIExvY2F0aW9uLURhdGEg QVZQIGluIGEyIERpYW1ldGVyLCBJIGFtIG5vdCBhYmxlIHRvCj4gICAgICAgIGZpbGwgQVZQIGNv ZGUgZm9yIGl0LiBVbnRpbCBpdCBpcyBjb252ZXJ0ZWQgdG8gYW4gUkZDIHRoZSBBVlAKPiAgICAg ICAgbnVtYmVycyB3b24ndCBiZSBhc3NpZ25lZCBieSBJQU5BLgo+Cj4KPgo+Cj4gICAgICAgICpU YWJsZSAqKjcuNCoqOiBEaWFtZXRlciBBVlBzIGRlZmluZWQgaW4gSUVURiBzcGVjaWZpY2F0aW9u cyoKPgo+ICAgICAgICAgKioKPgo+Cj4KPiAgICAgICAgKkFWUCBGbGFnIHJ1bGVzKgo+Cj4KPgo+ ICAgICAgICAgKioKPgo+ICAgICAgICAqQXR0cmlidXRlIE5hbWUqCj4KPgo+Cj4gICAgICAgICpB VlAgQ29kZSoKPgo+Cj4KPiAgICAgICAgKkNsYXVzZSBkZWZpbmVkKgo+Cj4KPgo+ICAgICAgICAq VmFsdWUgVHlwZSoKPgo+Cj4KPiAgICAgICAgKk11c3QqCj4KPgo+Cj4gICAgICAgICpNYXkqCj4K Pgo+Cj4gICAgICAgICpTaG91bGQgbm90Kgo+Cj4KPgo+ICAgICAgICAqTXVzdCBub3QqCj4KPgo+ Cj4gICAgICAgICpNYXkgRW5jcnlwdCoKPgo+ICAgICAgICBMb2NhdGlvbi1EYXRhCj4KPgo+Cj4g ICAgICAgIFRCRAo+Cj4KPgo+ICAgICAgICBbOCA8bWh0bWw6bWlkOi8vMDAwMDA0MzQvI3RpbmE4 Pl0KPgo+Cj4KPiAgICAgICAgT2N0ZXRTdHJpbmcKPgo+Cj4KPgo+Cj4KPgo+ICAgICAgICBNCj4K Pgo+Cj4KPgo+Cj4KPiAgICAgICAgVgo+Cj4KPgo+ICAgICAgICBObwo+Cj4gICAgICAgIE5PVEU6 ICAgICAgIFRoZSBBVlAgaGVhZGVyIGJpdCBkZW5vdGVkIGFzICJNIiwgaW5kaWNhdGVzIHdoZXRo ZXIKPiAgICAgICAgc3VwcG9ydCBvZiB0aGUgQVZQIGlzIHJlcXVpcmVkLiBUaGUgQVZQIGhlYWRl ciBiaXQgZGVub3RlZCBhcwo+ICAgICAgICAiViIsIGluZGljYXRlcyB3aGV0aGVyIHRoZSBvcHRp b25hbCBWZW5kb3LigJFJRCBmaWVsZCBpcyBwcmVzZW50Cj4gICAgICAgIGluIHRoZSBBVlAgaGVh ZGVyLgo+Cj4KPgo+Cj4gICAgICAgICAgICAgIDcuMy44ICBMb2NhdGlvbi1EYXRhIEFWUAo+Cj4g ICAgICAgIFRoZSBMb2NhdGlvbi1EYXRhIEFWUCBpcyBkZWZpbmVkIGluCj4gICAgICAgIGRyYWZ0 LWlldGYtZ2VvcHJpdi1yYWRpdXMtbG8tMTYgWzgKPiAgICAgICAgPG1odG1sOm1pZDovLzAwMDAw NDM0LyN0aW5hOD5dLiBJdCBjb250YWlucyBsb2NhdGlvbiBkYXRhIGluIHRoZQo+ICAgICAgICBm b3JtIG9mIGVpdGhlciBDaXZpYyBMb2NhdGlvbiBvciBHZW9zcGF0aWFsIExvY2F0aW9uLgo+Cj4K Pgo+Cj4KPiAgICAgICAgQi4gUi4KPiAgICAgICAgVGluYQo+ICAgICAgICBNZXNzZW5nZXJzOgo+ ICAgICAgICBNU046IHRpbmF0c291NkBob3RtYWlsLmNvbSA8bWFpbHRvOnRpbmF0c291NkBob3Rt YWlsLmNvbT4KPiAgICAgICAgWWFob286IHRpbmFfdHNvdSAgICBTa3lwZTogdGluYVRTT1UgICAg SmFiYmVyOiB0aW5hQGphYmJlci5vcmcKPiAgICAgICAgPG1haWx0bzp0aW5hQGphYmJlci5vcmc+ ICAgIEdvb2dsZSB0YWxrOiB0aW5hdHNvdTZAZ21haWwuY29tCj4gICAgICAgIDxtYWlsdG86dGlu YXRzb3U2QGdtYWlsLmNvbT4KPiAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4KPiAgICAgICAgTWFp bCBhcmNoaXZlIGZvciBUSVNQQU5fV0czIGNhbiBiZSBicm93c2VkIGF0IHRoZSBmb2xsb3dpbmcg dXJsIDoKPgo+ICAgICAgICBodHRwOi8vbGlzdC5ldHNpLm9yZy9USVNQQU5fV0czLmh0bWwKPgo+ ICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCj4gRGlNRSBtYWlsaW5nIGxpc3QKPiBEaU1FQGlldGYub3JnCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lCj4gCgoKX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRGlNRSBtYWlsaW5nIGxpc3QK RGlNRUBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUK From dime-bounces@ietf.org Tue Mar 11 15:33:19 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 980CF3A691E; Tue, 11 Mar 2008 15:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.427 X-Spam-Level: X-Spam-Status: No, score=-100.427 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxK+o0F9CV57; Tue, 11 Mar 2008 15:33:15 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEBEE3A6E58; Tue, 11 Mar 2008 15:33:10 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1599F28C216 for ; Tue, 11 Mar 2008 15:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wldoku2Fk0JN for ; Tue, 11 Mar 2008 15:33:08 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id A31763A6E43 for ; Tue, 11 Mar 2008 15:32:51 -0700 (PDT) Received: (qmail invoked by alias); 11 Mar 2008 22:30:31 -0000 Received: from dhcp-1575.ietf71.ietf.org (EHLO [130.129.21.117]) [130.129.21.117] by mail.gmx.net (mp033) with SMTP; 11 Mar 2008 23:30:31 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19cQ6F20vhcx44JJdCjRg+MangZGC7ArxjXWxko6F VCyuSEwjxJdwe/ Message-ID: <47D70804.8070704@gmx.net> Date: Wed, 12 Mar 2008 00:30:28 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: mboned@ietf.org References: <47D6F9D3.1000905@lab.ntt.co.jp> In-Reply-To: <47D6F9D3.1000905@lab.ntt.co.jp> X-Y-GMX-Trusted: 0 Cc: christian.jacquenet@francetelecom.com, bernard_aboba@hotmail.com, Hiroaki Sato , thayashi@digitalforest.co.jp, dime@ietf.org Subject: Re: [Dime] [ANCP] mboned multiaa-framework reflecting the ancp framework draft, request for review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Scott Bradner asked us a while ago to review your AAA framework draft. http://www.ops.ietf.org/lists/radiusext/2007/msg00528.html We at DIME did an initial review. You can find it here: http://www.ietf.org/mail-archive/web/dime/current/msg02007.html http://www.ietf.org/mail-archive/web/dime/current/msg01912.html http://www.ietf.org/mail-archive/web/dime/current/msg01899.html I recall that there were also reviews from the RADEXT working group. I don't see these reviews being addressed. I am also puzzled why the DIME and the RADEXT working group aren't get consulted more involved given that this is clearly about the AAA interworking. Ciao Hannes Hiroaki Sato wrote: > Hi all, > > We, the authors of draft-ietf-mboned-multiaaa-framework-06.txt, revised > our draft and some items refer to the ancp framework draft. > So, we'd like to request for you to review our draft and please comment > on it. > > Major changes include: > -two levels of accounting information (start/stop only and plus volume) > -acconting for fast channel change (information merging) > -QoS downgrade (admission control) > > thank you, > Hiroaki > > --- > ************************************ > NTT Network Service Systems Lab. > Hiroaki Sato > TEL:0422-59-4683 (+81-422-59-4683) > FAX:0422-59-5636 (+81-422-59-5636) > ************************************ > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Mar 11 16:49:35 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EDE73A6CD0; Tue, 11 Mar 2008 16:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.322 X-Spam-Level: X-Spam-Status: No, score=-99.322 tagged_above=-999 required=5 tests=[AWL=-0.551, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_HEAD_XUNSENT=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMpaKlQrQ6X7; Tue, 11 Mar 2008 16:49:34 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8AAD3A6C31; Tue, 11 Mar 2008 16:49:34 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6170A3A6CA9; Tue, 11 Mar 2008 16:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kU5SzNgDHMAu; Tue, 11 Mar 2008 16:49:32 -0700 (PDT) Received: from blu139-omc3-s8.blu139.hotmail.com (blu139-omc3-s8.blu139.hotmail.com [65.55.175.208]) by core3.amsl.com (Postfix) with ESMTP id 6FBFE3A6C7D; Tue, 11 Mar 2008 16:49:32 -0700 (PDT) Received: from BLU137-DS3 ([65.55.162.189]) by blu139-omc3-s8.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Mar 2008 16:47:13 -0700 X-Originating-IP: [130.129.19.169] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: To: "Hannes Tschofenig" , In-Reply-To: <47D6F9D3.1000905@lab.ntt.co.jp> <47D70804.8070704@gmx.net> References: <47D6F9D3.1000905@lab.ntt.co.jp> <47D70804.8070704@gmx.net> Date: Tue, 11 Mar 2008 16:47:23 -0700 MIME-Version: 1.0 X-Unsent: 1 X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MIMEOLE: Produced By Microsoft MimeOLE V12.0.1606 X-OriginalArrivalTime: 11 Mar 2008 23:47:13.0285 (UTC) FILETIME=[3ACB9350:01C883D2] Cc: christian.jacquenet@francetelecom.com, Hiroaki Sato , dime@ietf.org, radiusext@ops.ietf.org, thayashi@digitalforest.co.jp Subject: Re: [Dime] [ANCP] mboned multiaa-framework reflecting the ancp framework draft, request for review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I agree with Hannes. So far I have not seen any response on the RADEXT WG mailing list to the review of this document: http://ops.ietf.org/lists/radiusext/2007/msg00659.html -------------------------------------------------- From: "Hannes Tschofenig" Sent: Tuesday, March 11, 2008 3:30 PM To: Cc: "Hiroaki Sato" ; "Romascanu, Dan (Dan)" ; ; ; ; Subject: Re: [ANCP] mboned multiaa-framework reflecting the ancp framework draft, request for review > Scott Bradner asked us a while ago to review your AAA framework draft. > http://www.ops.ietf.org/lists/radiusext/2007/msg00528.html > > We at DIME did an initial review. You can find it here: > http://www.ietf.org/mail-archive/web/dime/current/msg02007.html > http://www.ietf.org/mail-archive/web/dime/current/msg01912.html > http://www.ietf.org/mail-archive/web/dime/current/msg01899.html > > I recall that there were also reviews from the RADEXT working group. > > I don't see these reviews being addressed. > > I am also puzzled why the DIME and the RADEXT working group aren't get > consulted more involved given that this is clearly about the AAA > interworking. > > Ciao > Hannes > > > Hiroaki Sato wrote: >> Hi all, >> >> We, the authors of draft-ietf-mboned-multiaaa-framework-06.txt, revised >> our draft and some items refer to the ancp framework draft. >> So, we'd like to request for you to review our draft and please comment >> on it. >> >> Major changes include: >> -two levels of accounting information (start/stop only and plus volume) >> -acconting for fast channel change (information merging) >> -QoS downgrade (admission control) >> >> thank you, >> Hiroaki >> >> --- >> ************************************ >> NTT Network Service Systems Lab. >> Hiroaki Sato >> TEL:0422-59-4683 (+81-422-59-4683) >> FAX:0422-59-5636 (+81-422-59-5636) >> ************************************ >> >> _______________________________________________ >> ANCP mailing list >> ANCP@ietf.org >> https://www.ietf.org/mailman/listinfo/ancp >> > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 12 07:25:39 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 680FC28C679; Wed, 12 Mar 2008 07:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.167 X-Spam-Level: X-Spam-Status: No, score=-97.167 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1, SARE_HEAD_HDR_XSPAMTST=1.111, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8dLeKzzpgr0; Wed, 12 Mar 2008 07:25:35 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EE6028C681; Wed, 12 Mar 2008 07:25:35 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFBB028C476 for ; Fri, 29 Feb 2008 00:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YSayxOnWr8f for ; Fri, 29 Feb 2008 00:02:11 -0800 (PST) Received: from khakasnet.ru (ns.khakasnet.ru [90.189.109.2]) by core3.amsl.com (Postfix) with ESMTP id 692CC28C164 for ; Fri, 29 Feb 2008 00:02:11 -0800 (PST) Received: from localhost ([127.0.0.1] helo=www.khakasnet.ru) by khakasnet.ru with esmtp (Exim 4.68) (envelope-from ) id 1JV0Be-00053p-8t for dime@ietf.org; Fri, 29 Feb 2008 15:01:46 +0700 Received: from 193.201.228.27 (proxying for 10.0.17.202) (SquirrelMail authenticated user rigir) by khakasnet.ru with HTTP; Fri, 29 Feb 2008 15:01:46 +0700 (KRAT) Message-ID: <16659.193.201.228.27.1204272106.squirrel@khakasnet.ru> Date: Fri, 29 Feb 2008 15:01:46 +0700 (KRAT) From: =?utf-8?Q?=F2=CF=CD=C1=CE?= To: dime@ietf.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release X-SpamTest-Info: Not protected X-Mailman-Approved-At: Wed, 12 Mar 2008 07:25:34 -0700 Subject: [Dime] Transient Failures in DCCA X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hello, Please, give the comments upon RFC 4006 on next conclusion: When server in CCA Update return Result_Code = 4010 or 4011 or 4012. Server MUST or not MUST wait from client CCR Terminate? Thank You. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 12 07:25:40 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1602928C681; Wed, 12 Mar 2008 07:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.436 X-Spam-Level: X-Spam-Status: No, score=-100.436 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnhR9bydr3BM; Wed, 12 Mar 2008 07:25:38 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A35FC28C6AB; Wed, 12 Mar 2008 07:25:35 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33B9028C827 for ; Wed, 5 Mar 2008 12:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QkhYixGhSD4 for ; Wed, 5 Mar 2008 12:08:41 -0800 (PST) Received: from web63610.mail.re1.yahoo.com (web63610.mail.re1.yahoo.com [69.147.97.80]) by core3.amsl.com (Postfix) with SMTP id 1AB8828C897 for ; Wed, 5 Mar 2008 12:04:33 -0800 (PST) Received: (qmail 35176 invoked by uid 60001); 5 Mar 2008 20:04:22 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=q3lnlL2kj7Nj1TPmucySl7uoTbDw3oX6JEfOuf0wZsqWENbmdRk3n6BPvKmo2D1PVlVSjSIVKKs1FIRfcruMIq8qndEp+37LK/1BeRq6SxqdRlJXBfvVoTJtTPVgRvKjX3iDSjzkxBj/TbssUCSIHHw8oCYxfzD5cHyFa/bOraU=; X-YMail-OSG: A3jG0iwVM1nRcVlA8B8mbqSUuOESdV7WKR6x.hlt3uUUJ6t2Y6V26sQweSaLpd3qrQ-- Received: from [76.19.255.157] by web63610.mail.re1.yahoo.com via HTTP; Wed, 05 Mar 2008 12:04:22 PST Date: Wed, 5 Mar 2008 12:04:22 -0800 (PST) From: Gerald Ash To: Magnus Westerlund , tsvwg , dime@ietf.org, NSIS In-Reply-To: <47C58EB8.1000203@ericsson.com> MIME-Version: 1.0 Message-ID: <714233.34555.qm@web63610.mail.re1.yahoo.com> X-Mailman-Approved-At: Wed, 12 Mar 2008 07:25:34 -0700 Cc: Jerry Ash Subject: Re: [Dime] [NSIS] WG last call on draft-ietf-tsvwg-emergency-rsvp-05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0187859105==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============0187859105== Content-Type: multipart/alternative; boundary="0-1660934183-1204747462=:34555" Content-Transfer-Encoding: 8bit --0-1660934183-1204747462=:34555 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit All, Here are some last call comments on draft-ietf-tsvwg-emergency-rsvp-05. General comments: 1. The emergency-rsvp approach does not prescribe end-to-end cross-domain consistent treatment of admission priority. As stated in Section 2 (Overview of RSVP extensions and Operations): "As an example of operation across multiple administrative domains, a first domain might decide to provide network layer admission priority to calls of a given Application Level Resource Priority and map it into a high RSVP admission control priority inside the Admission Priority Policy Element; while a second domain may decide to not provide admission priority to calls of this same Application Level Resource Priority and hence map it into a low RSVP admission control priority." So in this approach an emergency telecommunications service (ETS, e.g., GETS) might *not* get uniformly high admission priority treatment across administrative domains (ADs), depending on how the policy decision points (PDPs) in each AD decide to populate the RSVP Admission Priority element. This is in sharp contrast to the approach used in practice today for ETS/GETS, where high admission priority is applied end-to-end across domains. One reference as to how this approach operates in practice today for ETS/GETS can be found in http://www.amazon.com/Traffic-Engineering-Optimization-Integrated-Networks/dp/0123706254/ (Chapter 9 also presents extensive modeling & simulation analysis/case studies to show how today's end-to-end approach can operate across domains in the Internet). It would be good to motivate the rationale for the emergency-rsvp approach and why it makes sense to *not* ensure high end-to-end admission priority across domains for ETS/GETS services. 2. Presumably the emergency-rsvp admission priority approach is implemented (or planned to be implemented) in real network applications. It would be nice to reference such implementations, existing or planned, if possible. 3. The admission priority approach taken in nsis-qspec (http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-19.txt) is consistent with today's practice of providing high admission priority for ETS/GETS end-to-end across administrative domains. It does this by standardizing the admission priority values for the qspec object in an IANA registry, as specified in Section 7 (IANA considerations): "Admission Priority Parameter (8 bits): The following values are allocated by this specification: 0-2: assigned as specified in Section 6.2.9: Admission Priority 0: best-effort priority flow 1: normal priority flow 2: high priority flow The allocation policies for further values are as follows: 3-63: Standards Action 64-255: Reserved" It has been agreed on the nsis list to rename to in the qspec draft. To be consistent with this change, the emergency-rsvp approach should also be renamed (e.g., to ) to distinguish it from , and so that neither approach should be considered a 'generic' approach. Specific comments: 4. Section 3.1 (Admission Priority Policy Element) of emergency-rsvp states: "Adm. Priority (Admission Priority): 8 bits (unsigned) The admission control priority of the flow, in terms of access to network bandwidth in order to provide higher probability of call completion to selected flows. Higher values represent higher Priority. A given Admission Priority is encoded in this information element using the same value as when encoded in the Admission Priority parameter defined in section 6.2.9 of [NSIS-QSPEC], or in the Admission Priority parameter defined in section 4.10 of [DIME- PARAM]. In other words, a given value inside the Admission Priority information element defined in the present document, inside the [NSIS-QSPEC] Admission Priority parameter or inside the [DIME-PARAM] Admission Priority parameter, refers to the same Admission Priority." The text is very unclear as to what it means that admission priority values are encoded 'using the same value' in the 3 different drafts? Perhaps an example would help, but in any case it should be clarified. Further, the text should be updated to note that the field is not directly comparable to the field in the qspec draft so as to avoid confusion. 5. Sections A.1 and A.2 illustrate how the DSTE Maximum Allocation Model (MAM) and the DSTE Russian Dolls Model (RDM) can be used for support of rsvp admission priority. http://www.amazon.com/Traffic-Engineering-Optimization-Integrated-Networks/dp/0123706254/ presents extensive modeling & simulation analysis/case studies to show how the DSTE maximum allocation with reservation (MAR) model (http://www.ietf.org/rfc/rfc4126.txt?number=4126) performs for ETS/GETS services and how MAR performance compares very favorably to MAM performance. It would be appropriate to reference MAR as the third DSTE bandwidth constraints model available for consideration and perhaps also to reference the MAR/MAM performance analysis pertinent to emergency services. Jerry Magnus Westerlund wrote: This announces the second WG last call on "Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services" with the intended status of proposed standard: http://tools.ietf.org/id/draft-ietf-tsvwg-emergency-rsvp-05.txt This is the second one due to changes and the interaction with documents in the NSIS and DIME WG. Please provide any comments on the TSVWG mailing list no later than 28th of March. (Yes, it is long but that is due to the meeting and that we have several other WG last calls ongoing). Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ nsis mailing list nsis@ietf.org https://www.ietf.org/mailman/listinfo/nsis --------------------------------- Never miss a thing. Make Yahoo your homepage. --0-1660934183-1204747462=:34555 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
All,
 
Here are some last call comments on draft-ietf-tsvwg-emergency-rsvp-05.
 
General comments:
 
1. The emergency-rsvp approach does not prescribe end-to-end cross-domain consistent treatment of admission priority.  As stated in Section 2 (Overview of RSVP extensions and Operations):
 
  "As an example of operation across multiple administrative domains, a
   first domain might decide to provide network layer admission priority
   to calls of a given Application Level Resource Priority and map it
   into a high RSVP admission control priority inside the Admission
   Priority Policy Element; while a second domain may decide to not
   provide admission priority to calls of this same Application Level
   Resource Priority and hence map it into a low RSVP admission control
   priority."
 
So in this approach an emergency telecommunications service (ETS, e.g., GETS) might *not* get uniformly high admission priority treatment across administrative domains (ADs), depending on how the policy decision points (PDPs) in each AD decide to populate the RSVP Admission Priority element. 
 
This is in sharp contrast to the approach used in practice today for ETS/GETS, where high admission priority is applied end-to-end across domains.  One reference as to how this approach operates in practice today for ETS/GETS can be found in http://www.amazon.com/Traffic-Engineering-Optimization-Integrated-Networks/dp/0123706254/ (Chapter 9 also presents extensive modeling & simulation analysis/case studies to show how today's end-to-end approach can operate across domains in the Internet).
 
It would be good to motivate the rationale for the emergency-rsvp approach and why it makes sense to *not* ensure high end-to-end admission priority across domains for ETS/GETS services.
 
2. Presumably the emergency-rsvp admission priority approach is implemented (or planned to be implemented) in real network applications.  It would be nice to reference such implementations, existing or planned, if possible.
 
3. The admission priority approach taken in nsis-qspec (http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-19.txt) is consistent with today's practice of providing high admission priority for ETS/GETS end-to-end across administrative domains.  It does this by standardizing the admission priority values for the qspec object in an IANA registry, as specified in Section 7 (IANA considerations):
 
  "Admission Priority Parameter (8 bits):
   The following values are allocated by this specification:
   0-2: assigned as specified in Section 6.2.9:
   Admission Priority 0: best-effort priority flow
                      1: normal priority flow
                      2: high priority flow
   The allocation policies for further values are as follows:
   3-63: Standards Action
   64-255: Reserved"
 
It has been agreed on the nsis list to rename <Admission Priority> to <Y.2171 Admission Priority> in the qspec draft.  To be consistent with this change, the emergency-rsvp approach should also be renamed (e.g., to <RSVP Admission Priority>) to distinguish it from <Y.2171 Admission Priority>, and so that neither approach should be considered a 'generic' approach.
 
Specific comments:
 
4. Section 3.1 (Admission Priority Policy Element) of emergency-rsvp states:
 
  "Adm. Priority (Admission Priority): 8 bits (unsigned)
   The admission control priority of the flow, in terms of access to
   network bandwidth in order to provide higher probability of call
   completion to selected flows. Higher values represent higher 
   Priority. A given Admission Priority is encoded in this information
   element using the same value as when encoded in the Admission
   Priority parameter defined in section 6.2.9 of [NSIS-QSPEC], or in
   the Admission Priority parameter defined in section 4.10 of [DIME-
   PARAM]. In other words, a given value inside the Admission Priority
   information element defined in the present document, inside the
   [NSIS-QSPEC] Admission Priority parameter or inside the [DIME-PARAM]
   Admission Priority parameter, refers to the same Admission Priority."
 
The text is very unclear as to what it means that admission priority values are encoded 'using the same value' in the 3 different drafts?  Perhaps an example would help, but in any case it should be clarified.  Further, the text should be updated to note that the <rsvp admission priority> field is not directly comparable to the <Y.2171 Admission Priority> field in the qspec draft so as to avoid confusion.
 
5. Sections A.1 and A.2 illustrate how the DSTE Maximum Allocation Model (MAM) and the DSTE Russian Dolls Model (RDM) can be used for support of rsvp admission priority.  http://www.amazon.com/Traffic-Engineering-Optimization-Integrated-Networks/dp/0123706254/ presents extensive modeling & simulation analysis/case studies to show how the DSTE maximum allocation with reservation (MAR) model (http://www.ietf.org/rfc/rfc4126.txt?number=4126) performs for ETS/GETS services and how MAR performance compares very favorably to MAM performance.  It would be appropriate to reference MAR as the third DSTE bandwidth constraints model available for consideration and perhaps also to reference the MAR/MAM performance analysis pertinent to emergency services.
 
Jerry


Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
This announces the second WG last call on "Resource ReSerVation Protovol
(RSVP) Extensions for Emergency Services" with the intended status of
proposed standard:

http://tools.ietf.org/id/draft-ietf-tsvwg-emergency-rsvp-05.txt

This is the second one due to changes and the interaction with documents
in the NSIS and DIME WG. Please provide any comments on the TSVWG
mailing list no later than 28th of March. (Yes, it is long but that is
due to the meeting and that we have several other WG last calls ongoing).

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB | Phone +46 8 4048287
Torshamsgatan 23 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

_______________________________________________
nsis mailing list
nsis@ietf.org
https://www.ietf.org/mailman/listinfo/nsis

Never miss a thing. Make Yahoo your homepage. --0-1660934183-1204747462=:34555-- --===============0187859105== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0187859105==-- From dime-bounces@ietf.org Wed Mar 12 07:25:40 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4D1228C681; Wed, 12 Mar 2008 07:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.937 X-Spam-Level: X-Spam-Status: No, score=-96.937 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yo9FVjgbQgcc; Wed, 12 Mar 2008 07:25:35 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BD2028C3E8; Wed, 12 Mar 2008 07:25:35 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A73C328C178 for ; Wed, 27 Feb 2008 23:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2i6O9YikncS0 for ; Wed, 27 Feb 2008 23:47:07 -0800 (PST) Received: from f169.mail.ru (f169.mail.ru [194.67.57.141]) by core3.amsl.com (Postfix) with ESMTP id 2E55C28C140 for ; Wed, 27 Feb 2008 23:47:06 -0800 (PST) Received: from mail by f169.mail.ru with local id 1JUdTn-0007xd-00 for dime@ietf.org; Thu, 28 Feb 2008 10:46:59 +0300 Received: from [193.201.228.27] by win.mail.ru with HTTP; Thu, 28 Feb 2008 10:46:59 +0300 From: =?koi8-r?Q?=F2=CF=CD=C1=CE_=E7=C9=D2=DB?= To: dime@ietf.org Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: 10.0.17.202 via proxy [193.201.228.27] Date: Thu, 28 Feb 2008 10:46:59 +0300 Message-Id: X-Mailman-Approved-At: Wed, 12 Mar 2008 07:25:34 -0700 Subject: [Dime] State a case RFC 4006 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: =?koi8-r?Q?=F2=CF=CD=C1=CE_=E7=C9=D2=DB?= List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hello My name is Roman. Please, give the comments upon RFC 4006 (Diameter Credit-Control Application) on next conclusion: When server in CCA Update return Result_Code = 4010 or 4011 or 4012. Server MUST or not MUST wait from client CCR Terminate? Thank You. Sorry to trouble you. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 12 07:25:41 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D497528C6B5; Wed, 12 Mar 2008 07:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.436 X-Spam-Level: X-Spam-Status: No, score=-100.436 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iw-Uk2kG8hVF; Wed, 12 Mar 2008 07:25:40 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB76D28C6B7; Wed, 12 Mar 2008 07:25:35 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DEBF28C913 for ; Thu, 6 Mar 2008 08:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMR7igqtWqz2 for ; Thu, 6 Mar 2008 08:57:41 -0800 (PST) Received: from web63606.mail.re1.yahoo.com (web63606.mail.re1.yahoo.com [69.147.97.76]) by core3.amsl.com (Postfix) with SMTP id 9B5E028C916 for ; Thu, 6 Mar 2008 08:57:40 -0800 (PST) Received: (qmail 387 invoked by uid 60001); 6 Mar 2008 16:57:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=qxDszBdfUdDqhaNZOxkjnko/y4w//F61DAipizn8gpugVZyQ1HAfmFJC8P5W0U0mDxasqrXtZvg7369rLCW2tDa6zMfKx6hHJkCSjkz+zDFzkp2rSu6bpRZwgImUbw8VFgO634u7+b2Hqw0JZo+5/moaIGYRRn7zMPg36tPgcvc=; X-YMail-OSG: r4k4Nl4VM1lTGyoUe.J_zIziXtIlIBIJ6mWJrxT4IaZKLvsK.gcHKcj14DR9S24DoXhldcIkHlqyEc0QSpPlFJsWQQ-- Received: from [76.19.255.157] by web63606.mail.re1.yahoo.com via HTTP; Thu, 06 Mar 2008 08:57:29 PST Date: Thu, 6 Mar 2008 08:57:29 -0800 (PST) From: Gerald Ash To: Francois Le Faucheur IMAP , tsvwg , dime@ietf.org, NSIS In-Reply-To: <508848E3-230B-40F9-8BFD-F10036348387@cisco.com> MIME-Version: 1.0 Message-ID: <940378.320.qm@web63606.mail.re1.yahoo.com> X-Mailman-Approved-At: Wed, 12 Mar 2008 07:25:34 -0700 Cc: Jerry Ash Subject: Re: [Dime] [NSIS] WG last call on draft-ietf-tsvwg-emergency-rsvp-05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1859513374==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1859513374== Content-Type: multipart/alternative; boundary="0-883187126-1204822649=:320" Content-Transfer-Encoding: 8bit --0-883187126-1204822649=:320 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Francois, A couple more comments. >> It would be good to motivate the rationale for the emergency-rsvp approach >> and why it makes sense to *not* ensure high end-to-end admission priority >> across domains for ETS/GETS services. > The approach is the following: > * the overall requirement for Emergency services is to achieve "elevated > probability of session establishment" > > * there are multiple mechanisms (Admission Priority, Preemption, "Call > Queueing") that can be combined in different ways in a given network that > will ENSURE "elevated probability of session establishment" _through that > given network_ > * in addition, there is a mechanism allowing each operator to identify an > emergency session transiting their network and invoke the corresponding set > of mechanism in that network. As a result, the solution allows "elevated > probability of session establishment" _end-to-end_, which is the real > objective. > > So, in a nutshell the approach focuses on allowing end-to-end "elevated > probability of session establishment" but it is felt that while this may > involve admission priority, this does not necessarily dictate end-to-end > admission priority. > > This was discussed at length in the TSVWG. Some operators pointed out that > in their region/country Emergency services would use mechanism A while > others would use mechanism B, while other would use a combination of > mechanisms. Some pointed out that local regulations prevented use of a > particular mechanism in a geography while not in another. As agreed by the > WG, this discussion was captured in Appendix B illustrating various > combinations that an operator may use to achieve "elevated probability of > session establishment" . > > More generally, I think it was felt that IETF was not chartered to mandate a > specific combination of mechanisms that MUST be deployed in each and every > network. Rather, the IETF needs to make available the mechanisms that can be > combined to achieve the end to end objective. > [an analogy that comes to mind is the Voice QoS space. The IETF has defined > many QoS mechanisms : Diff-Serv, MPLS Traffic Engineering, MPLS FRR, MPLS > Diffserv-aware TE, .... However, the IETF does not mandate that a very > specific combination of those be used in each and every network carrying > voice.] > > My perception is that the above approach is sufficiently described in the > current draft (section 2, appendix B,..). But if you have specific > suggestions on how to present it more clearly, we can certainly accommodate > that. Thanks for the explanation, it helps to clarify the intent. However, IMO this intent does not come through in the text (abstract, Section 1, Section 2). The draft focuses on admission priority, e.g., the abstract says: "This document specifies RSVP extensions that can be used to support such an admission priority capability at the network layer... Other solution components, or other solutions, are outside the scope of this document." And the example you give in Section 2 leaves one wondering how ETS achieves the elevated probability of session establishment when one domain gives low admission priority: "As an example of operation across multiple administrative domains, a first domain might decide to provide network layer admission priority to calls of a given Application Level Resource Priority and map it into a high RSVP admission control priority inside the Admission Priority Policy Element; while a second domain may decide to not provide admission priority to calls of this same Application Level Resource Priority and hence map it into a low RSVP admission control priority." Presumably the second domain uses some other mechanism (e.g., call queueing) to achieve elevated probability of call establishment. IMO this should be mentioned in the example. More generally, perhaps you can add some of your clarifying words somewhere in Section 1 and/or in the above example and/or perhaps add a sentence to the abstract. E.g., extracting from your explanation you could add something like the following: "The overall requirement for ETS is to achieve an elevated probability of session establishment (EPSE) by applying multiple mechanisms (e.g., admission priority, preemption, "call queueing") that can be combined in different ways in a given network to achieve EPSE. As such, each operator can identify an emergency session transiting their network and invoke the corresponding mechanism(s) in that network to achieve EPSE. For example, some operators may use mechanism A while others would use mechanism B, while others would use a combination of mechanisms. Appendix B illustrates various combinations that an operator may use to achieve EPSE." >> 3. The admission priority approach taken in nsis-qspec >> (http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-19.txt) is >> consistent with today's practice of providing high admission priority for >> ETS/GETS end-to-end across administrative domains. It does this by >> standardizing the admission priority values for the qspec object in an IANA >> registry, as specified in Section 7 (IANA considerations): >> >> "Admission Priority Parameter (8 bits): >> The following values are allocated by this specification: >> 0-2: assigned as specified in Section 6.2.9: >> Admission Priority 0: best-effort priority flow >> 1: normal priority flow >> 2: high priority flow >> The allocation policies for further values are as follows: >> 3-63: Standards Action >> 64-255: Reserved" >> >> It has been agreed on the nsis list to rename to >> in the qspec draft. To be consistent with this >> change, the emergency-rsvp approach should also be renamed (e.g., to > Admission Priority>) to distinguish it from , and >> so that neither approach should be considered a 'generic' approach. > I am not sure why the RSVP Admission is no longer generic (it can be used to > convey the Y.2171 values if an operator so desires, it can be used to carry > other values too). Let me make sure I have this straight. In the NSIS discussion you insist that we change the name to in order to resolve the debate, while the NSIS admission priority approach is in fact as implemented today for ETS and has little to do with Y.2171 other than to populate the initial admission priority values in the registry. OTOH, the rsvp admission priority approach uses a specific rsvp object, is populated from an rsvp-specific p-type, and AFAIK is not implemented anywhere as yet. Yet this rsvp-specific admission priority approach is now declared the 'generic' admission priority mechanism? Hopefully you'll also respond to my comments 2 & 4: 2. Presumably the emergency-rsvp admission priority approach is implemented (or planned to be implemented) in real network applications. It would be nice to reference such implementations, existing or planned, if possible. 4. Section 3.1 (Admission Priority Policy Element) of emergency-rsvp states: "Adm. Priority (Admission Priority): 8 bits (unsigned) The admission control priority of the flow, in terms of access to network bandwidth in order to provide higher probability of call completion to selected flows. Higher values represent higher Priority. A given Admission Priority is encoded in this information element using the same value as when encoded in the Admission Priority parameter defined in section 6.2.9 of [NSIS-QSPEC], or in the Admission Priority parameter defined in section 4.10 of [DIME- PARAM]. In other words, a given value inside the Admission Priority information element defined in the present document, inside the [NSIS-QSPEC] Admission Priority parameter or inside the [DIME-PARAM] Admission Priority parameter, refers to the same Admission Priority." The text is very unclear as to what it means that admission priority values are encoded 'using the same value' in the 3 different drafts? Perhaps an example would help, but in any case it should be clarified. Further, the text should be updated to note that the field is not directly comparable to the field in the qspec draft so as to avoid confusion. Jerry --------------------------------- Never miss a thing. Make Yahoo your homepage. --0-883187126-1204822649=:320 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Francois,
 
A couple more comments.
 
>> It would be good to motivate the rationale for the emergency-rsvp approach
>> and why it makes sense to *not* ensure high end-to-end admission priority
>> across domains for ETS/GETS services.
 
> The approach is the following:
> * the overall requirement for Emergency services is to achieve "elevated
> probability of session establishment"
>
> * there are multiple mechanisms (Admission Priority, Preemption, "Call
> Queueing") that can be combined in different ways in a given network that
> will ENSURE "elevated probability of session establishment" _through that
> given network_
> * in addition, there is a mechanism allowing each operator to identify an
> emergency session transiting their network and invoke the corresponding set
> of mechanism in that network. As a result, the solution allows "elevated
> probability of session establishment" _end-to-end_, which is the real
> objective.
> 
> So, in a nutshell the approach focuses on allowing end-to-end "elevated
> probability of session establishment" but it is felt that while this may
> involve admission priority, this does not necessarily dictate end-to-end
> admission priority.
> 
> This was discussed at length in the TSVWG. Some operators pointed out that
> in their region/country Emergency services would use mechanism A while
> others would use mechanism B, while other would use a combination of
> mechanisms. Some pointed out that local regulations prevented use of a
> particular mechanism in a geography while not in another. As agreed by the
> WG, this discussion was captured in Appendix B illustrating various
> combinations that an operator may use to achieve "elevated probability of
> session establishment" .
> 
> More generally, I think it was felt that IETF was not chartered to mandate a
> specific combination of mechanisms that MUST be deployed in each and every
> network. Rather, the IETF needs to make available the mechanisms that can be
> combined to achieve the end to end objective.
> [an analogy that comes to mind is the Voice QoS space. The IETF has defined
> many QoS mechanisms : Diff-Serv, MPLS Traffic Engineering, MPLS FRR, MPLS
> Diffserv-aware TE, .... However, the IETF does not mandate that a very
> specific combination of those be used in each and every network carrying
> voice.]
> 
> My perception is that the above approach is sufficiently described in the
> current draft (section 2, appendix B,..). But if you have specific
> suggestions on how to present it more clearly, we can certainly accommodate
> that.
 
Thanks for the explanation, it helps to clarify the intent.  However, IMO this intent does not come through in the text (abstract, Section 1, Section 2).  The draft focuses on admission priority, e.g., the abstract says:
 
"This document specifies RSVP extensions that can be used to support
   such an admission priority capability at the network layer...
   Other solution components, or other
   solutions, are outside the scope of this document."
 
And the example you give in Section 2 leaves one wondering how ETS achieves the elevated probability of session establishment when one domain gives low admission priority:
 
"As an example of operation across multiple administrative domains, a
   first domain might decide to provide network layer admission priority
   to calls of a given Application Level Resource Priority and map it
   into a high RSVP admission control priority inside the Admission
   Priority Policy Element; while a second domain may decide to not
   provide admission priority to calls of this same Application Level
   Resource Priority and hence map it into a low RSVP admission control
   priority."
 
Presumably the second domain uses some other mechanism (e.g., call queueing) to achieve elevated probability of call establishment.  IMO this should be mentioned in the example.
 
More generally, perhaps you can add some of your clarifying words somewhere in Section 1 and/or in the above example and/or perhaps add a sentence to the abstract.  E.g., extracting from your explanation you could add something like the following:
 
"The overall requirement for ETS is to achieve an elevated probability of session establishment (EPSE) by applying multiple mechanisms (e.g., admission priority, preemption, "call queueing") that can be combined in different ways in a given network to achieve EPSE.  As such, each operator can identify an emergency session transiting their network and invoke the corresponding mechanism(s) in that network to achieve EPSE.  For example, some operators may use mechanism A while others would use mechanism B, while others would use a combination of mechanisms.  Appendix B illustrates various combinations that an operator may use to achieve EPSE."
 
>> 3. The admission priority approach taken in nsis-qspec
>> (http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-19.txt) is
>> consistent with today's practice of providing high admission priority for
>> ETS/GETS end-to-end across administrative domains.  It does this by
>> standardizing the admission priority values for the qspec object in an IANA
>> registry, as specified in Section 7 (IANA considerations):
>>
>>  "Admission Priority Parameter (8 bits):
>>   The following values are allocated by this specification:
>>   0-2: assigned as specified in Section 6.2.9:
>>   Admission Priority 0: best-effort priority flow
>>                     1: normal priority flow
>>                      2: high priority flow
>>   The allocation policies for further values are as follows:
>>   3-63: Standards Action
>>   64-255: Reserved"
>>
>> It has been agreed on the nsis list to rename <Admission Priority> to
>> <Y.2171 Admission Priority> in the qspec draft.  To be consistent with this
>> change, the emergency-rsvp approach should also be renamed (e.g., to <RSVP
>> Admission Priority>) to distinguish it from <Y.2171 Admission Priority>, and
>> so that neither approach should be considered a 'generic' approach.
> I am not sure why the RSVP Admission is no longer generic (it can be used to
> convey the Y.2171 values if an operator so desires, it can be used to carry
> other values too).
 
Let me make sure I have this straight.  In the NSIS discussion you insist that we change the name to <Y.2171 Admission Priority> in order to resolve the debate, while the NSIS admission priority approach is in fact as implemented today for ETS and has little to do with Y.2171 other than to populate the initial admission priority values in the registry.  OTOH, the rsvp admission priority approach uses a specific rsvp object, is populated from an rsvp-specific p-type, and AFAIK is not implemented anywhere as yet.  Yet this rsvp-specific admission priority approach is now declared the 'generic' admission priority mechanism?
 
Hopefully you'll also respond to my comments 2 & 4:
 
2. Presumably the emergency-rsvp admission priority approach is implemented (or planned to be implemented) in real network applications.  It would be nice to reference such implementations, existing or planned, if possible.
 
4. Section 3.1 (Admission Priority Policy Element) of emergency-rsvp states:
 
  "Adm. Priority (Admission Priority): 8 bits (unsigned)
   The admission control priority of the flow, in terms of access to
   network bandwidth in order to provide higher probability of call
   completion to selected flows. Higher values represent higher 
   Priority. A given Admission Priority is encoded in this information
   element using the same value as when encoded in the Admission
   Priority parameter defined in section 6.2.9 of [NSIS-QSPEC], or in
   the Admission Priority parameter defined in section 4.10 of [DIME-
   PARAM]. In other words, a given value inside the Admission Priority
   information element defined in the present document, inside the
   [NSIS-QSPEC] Admission Priority parameter or inside the [DIME-PARAM]
   Admission Priority parameter, refers to the same Admission Priority."
 
The text is very unclear as to what it means that admission priority values are encoded 'using the same value' in the 3 different drafts?  Perhaps an example would help, but in any case it should be clarified.  Further, the text should be updated to note that the <rsvp admission priority> field is not directly comparable to the <Y.2171 Admission Priority> field in the qspec draft so as to avoid confusion.
 
Jerry

Never miss a thing. Make Yahoo your homepage. --0-883187126-1204822649=:320-- --===============1859513374== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1859513374==-- From dime-bounces@ietf.org Wed Mar 12 07:25:47 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0CEA28C6D6; Wed, 12 Mar 2008 07:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.35 X-Spam-Level: X-Spam-Status: No, score=-100.35 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1rcCUI2Usrp; Wed, 12 Mar 2008 07:25:46 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B98D28C701; Wed, 12 Mar 2008 07:25:36 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50EA43A6A61; Wed, 12 Mar 2008 06:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urW2GS+I-e6v; Wed, 12 Mar 2008 06:54:32 -0700 (PDT) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by core3.amsl.com (Postfix) with ESMTP id 42CDE3A6B9C; Wed, 12 Mar 2008 06:54:32 -0700 (PDT) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama500.ecl.ntt.co.jp (8.14.2/8.14.2) with ESMTP id m2CDpwmQ002616; Wed, 12 Mar 2008 22:51:58 +0900 (JST) Received: from mfs6.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 9B2E46BFB; Wed, 12 Mar 2008 22:51:58 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (eclscan2.m.ecl.ntt.co.jp [129.60.5.68]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 7906D6B9E; Wed, 12 Mar 2008 22:51:58 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m2CDpvNh019672; Wed, 12 Mar 2008 22:51:58 +0900 (JST) Received: from imh.m.ecl.ntt.co.jp (imh0.m.ecl.ntt.co.jp [129.60.5.146]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m2CDpv9f019669; Wed, 12 Mar 2008 22:51:57 +0900 (JST) Received: from [127.0.0.1] ([129.60.13.7]) by imh.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m2CDpuWT001837; Wed, 12 Mar 2008 22:51:57 +0900 (JST) Message-ID: <47D7E09D.8010307@lab.ntt.co.jp> Date: Wed, 12 Mar 2008 22:54:37 +0900 From: Hiroaki Sato User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Bernard_Aboba@hotmail.com References: <47D6F9D3.1000905@lab.ntt.co.jp> <47D70804.8070704@gmx.net> In-Reply-To: X-Mailman-Approved-At: Wed, 12 Mar 2008 07:25:34 -0700 Cc: christian.jacquenet@francetelecom.com, thayashi@digitalforest.co.jp, radiusext@ops.ietf.org, mboned@ietf.org, dime@ietf.org Subject: Re: [Dime] [ANCP] mboned multiaa-framework reflecting the ancp framework draft, request for review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Thank you for telling me. We reflected RADEXT comments recieved from Alan. It seems like http://ops.ietf.org/lists/radiusext/2007/msg00659.html. And I replied to radiusext@ops.ietf.org on 2007/11/26. Actually, most of comments were reflected to -05 version. I'll check it once more. Hiroaki > I agree with Hannes. > > So far I have not seen any response on the RADEXT WG mailing list to the > review of this document: > http://ops.ietf.org/lists/radiusext/2007/msg00659.html > > -------------------------------------------------- > From: "Hannes Tschofenig" > Sent: Tuesday, March 11, 2008 3:30 PM > To: > Cc: "Hiroaki Sato" ; "Romascanu, Dan (Dan)" > ; ; > ; ; > > Subject: Re: [ANCP] mboned multiaa-framework reflecting the ancp > framework draft, request for review > >> Scott Bradner asked us a while ago to review your AAA framework draft. >> http://www.ops.ietf.org/lists/radiusext/2007/msg00528.html >> >> We at DIME did an initial review. You can find it here: >> http://www.ietf.org/mail-archive/web/dime/current/msg02007.html >> http://www.ietf.org/mail-archive/web/dime/current/msg01912.html >> http://www.ietf.org/mail-archive/web/dime/current/msg01899.html >> >> I recall that there were also reviews from the RADEXT working group. >> >> I don't see these reviews being addressed. >> >> I am also puzzled why the DIME and the RADEXT working group aren't get >> consulted more involved given that this is clearly about the AAA >> interworking. >> >> Ciao >> Hannes >> >> >> Hiroaki Sato wrote: >>> Hi all, >>> >>> We, the authors of draft-ietf-mboned-multiaaa-framework-06.txt, revised >>> our draft and some items refer to the ancp framework draft. >>> So, we'd like to request for you to review our draft and please comment >>> on it. >>> >>> Major changes include: >>> -two levels of accounting information (start/stop only and plus volume) >>> -acconting for fast channel change (information merging) >>> -QoS downgrade (admission control) >>> >>> thank you, >>> Hiroaki >>> >>> --- >>> ************************************ >>> NTT Network Service Systems Lab. >>> Hiroaki Sato >>> TEL:0422-59-4683 (+81-422-59-4683) >>> FAX:0422-59-5636 (+81-422-59-5636) >>> ************************************ >>> >>> _______________________________________________ >>> ANCP mailing list >>> ANCP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ancp >>> >> >> > > -- ************************************ NTT Network Service Systems Lab. Hiroaki Sato TEL:0422-59-4683 (+81-422-59-4683) FAX:0422-59-5636 (+81-422-59-5636) ************************************ _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 12 07:25:49 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03C9228C729; Wed, 12 Mar 2008 07:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.836 X-Spam-Level: X-Spam-Status: No, score=-98.836 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, DEAR_SOMETHING=1.605, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYv08Jx2hPTK; Wed, 12 Mar 2008 07:25:44 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F45528C6F0; Wed, 12 Mar 2008 07:25:36 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ED5C28C726 for ; Wed, 12 Mar 2008 06:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaH4HQQu+cgc for ; Wed, 12 Mar 2008 06:34:31 -0700 (PDT) Received: from chemail01.che.aricent.com (unknown [125.17.107.171]) by core3.amsl.com (Postfix) with ESMTP id 3FC3728C71E for ; Wed, 12 Mar 2008 06:33:28 -0700 (PDT) To: dime@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Build V655_10312005 October 31, 2005 Message-ID: From: Suriyanarayanan B Date: Wed, 12 Mar 2008 19:01:04 +0530 X-MIMETrack: Serialize by Router on Chemail01/CHE/HSS(Release 6.5.5|November 30, 2005) at 03/12/2008 07:01:09 PM, Serialize complete at 03/12/2008 07:01:09 PM X-Mailman-Approved-At: Wed, 12 Mar 2008 07:25:34 -0700 Subject: [Dime] Fw: Regarding IPFilterRule and QoSFilterRule AVP Data Formats in RFC 3588 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0119351729==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============0119351729== Content-Type: multipart/alternative; boundary="=_alternative 004A42096525740A_=" This is a multipart message in MIME format. --=_alternative 004A42096525740A_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable -----=20Forwarded=20by=20Suriyanarayanan=20B/CHE/HSS=20on=2003/12/2008=20= 06:59=20PM=20-----=0D=0A=0D=0A"David=20Frascone"=20=20= =0D=0ASent=20by:=20frascone@gmail.com=0D=0A03/12/2008=2006:31=20PM=0D=0A= =0D=0A=0D=0ATo=0D=0ASuriyanarayanan=20B/CHE/HSS@HSS=0D=0Acc=0D=0A=0D=0ASu= bject=0D=0ARe:=20Regarding=20IPFilterRule=20and=20QoSFilterRule=20AVP=20D= ata=20Formats=20in=20RFC=203588=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A= You=20have=20e-mailed=20the=20owner=20of=20the=20diameter=20developers'= =20mailing=20list.=0D=0A=0D=0APlease=20direct=20questions=20related=20to= =20the=20protocol=20to=20the=20diameter=20extensions=20=0D=0Amailing=20li= st,=20dime@ietf.org.=0D=0A=0D=0A-Dave=0D=0A=0D=0AOn=20Wed,=20Mar=2012,=20= 2008=20at=205:05=20AM,=20Suriyanarayanan=20B=20=20= =0D=0Awrote:=0D=0A=0D=0ADear=20Sir/Madam,=20=0D=0A=0D=0AI=20have=20an=20i= ssue=20to=20be=20discussed=20on=20Request=20for=20Comments:=203588.=20=0D= =0A=0D=0AIn=20RFC=203588,=20Section=204.3.=20(=20Derived=20AVP=20Data=20F= ormats),=20IPFilterRule=20and=20=0D=0AQoSFilterRule=20are=20Specifed=20as= =20the=20derived=20data=20formats=20from=20the=20=0D=0AOctetString=20AVP= =20Base=20format.=20=0D=0ABased=20on=20the=20definition=20given,=20shall= =20we=20consider=20the=20above=20two=20data=20=0D=0Aformats=20to=20be=20t= aken=20in=20ABNF=20format.=20If=20so=20what=20is=20the=20ABNF=20grammar= =20for=20=0D=0Athat.=20=0D=0A=0D=0ASo=20Please=20confirm=20me=20the=20sam= e=20as=20soon=20as=20possible.=20=0D=0A=0D=0AThanks=20&=20Regards=20=0D= =0ASuriya=20Narayanan=20B=20=0D=0A=20Software=20Engineer=20=0D=0A=20A=20R= =20I=20C=20E=20N=20T=20=0D=0A=20Plot=20No.5,=20Espee=20IT=20Park,=203rd= =20Floor,=20=0D=0A=20Jawaharlal=20Nehru=20Salai,=20Ekkattuthangal,=20=0D= =0A=20Guindy,=20Chennai=20?=20600097=20=0D=0A=20Main:=20+91=2044=20662163= 69=20=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A***********************=20=20Ari= cent-Restricted=20=20=20***********************=20=0D=0A"DISCLAIMER:=20Th= is=20message=20is=20proprietary=20to=20Aricent=20and=20is=20intended=20so= lely=20=0D=0Afor=20the=20use=20of=20=0D=0Athe=20individual=20to=20whom=20= it=20is=20addressed.=20It=20may=20contain=20privileged=20or=20=0D=0Aconfi= dential=20information=20and=20should=20not=20be=20=0D=0Acirculated=20or= =20used=20for=20any=20purpose=20other=20than=20for=20what=20it=20is=20int= ended.=20If=20=0D=0Ayou=20have=20received=20this=20message=20in=20error,= =20=0D=0Aplease=20notify=20the=20originator=20immediately.=20If=20you=20a= re=20not=20the=20intended=20=0D=0Arecipient,=20you=20are=20notified=20tha= t=20you=20are=20strictly=0D=0Aprohibited=20from=20using,=20copying,=20alt= ering,=20or=20disclosing=20the=20contents=20of=20=0D=0Athis=20message.=20= Aricent=20accepts=20no=20responsibility=20for=20=0D=0Aloss=20or=20damage= =20arising=20from=20the=20use=20of=20the=20information=20transmitted=20by= =20this=20=0D=0Aemail=20including=20damage=20from=20virus."=0D=0A=0D=0A= =0D=0A=0D=0A***********************=20=20Aricent-=20Confidential=20=20=20= ***********************=0D=0A"DISCLAIMER:=20This=20message=20is=20proprie= tary=20to=20Aricent=20and=20is=20intended=20solely=20for=20the=20use=20of= =20=0Athe=20individual=20to=20whom=20it=20is=20addressed.=20It=20may=20co= ntain=20privileged=20or=20confidential=20information=20and=20should=20not= =20be=20=0Acirculated=20or=20used=20for=20any=20purpose=20other=20than=20= for=20what=20it=20is=20intended.=20If=20you=20have=20received=20this=20me= ssage=20in=20error,=20=0Aplease=20notify=20the=20originator=20immediately= .=20If=20you=20are=20not=20the=20intended=20recipient,=20you=20are=20noti= fied=20that=20you=20are=20strictly=0Aprohibited=20from=20using,=20copying= ,=20altering,=20or=20disclosing=20the=20contents=20of=20this=20message.= =20Aricent=20accepts=20no=20responsibility=20for=20=0Aloss=20or=20damage= =20arising=20from=20the=20use=20of=20the=20information=20transmitted=20by= =20this=20email=20including=20damage=20from=20virus."=0A --=_alternative 004A42096525740A_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0D=0A
-----= =20Forwarded=20by=20Suriyanarayanan=0D=0AB/CHE/HSS=20on=2003/12/2008=2006= :59=20PM=20-----=0D=0A
=0D=0A=0D=0A=0D=0A"David=20Frascone"=0D=0A<dave@frascone.com>=20<= /font>=0D=0A
Sent=20by:=20frasc= one@gmail.com=0D=0A

03/12= /2008=2006:31=20PM=0D=0A
=0D=0A=0D=0A=0D=0A=0D=0A=0D=0ATo=0D=0ASuriyanarayanan=20B/CHE/HSS@HSS= =0D=0A=0D=0A=0D=0Acc=0D=0A=0D=0A=0D=0A= =0D=0ASubject= =0D=0ARe:=20Regarding=20IPFilterRule=0D=0Aand=20QoSFilterRule=20AVP=20Data= =20Formats=20in=20 =20 =20 =20 =20RFC=0D=0A3588=0D=0A
=0D=0A=0D=0A=0D=0A
=0D=0A=
=0D=0A
=0D=0A
=0D=0A
=0D=0A
You=20have=20e-mailed=20the=20owner=20of=20the=20diameter=20develope= rs'=0D=0Amailing=20list.
=0D=0A
=0D=0APlease=20direct=20questions= =20related=20to=20the=20protocol=20to=20the=20diameter=20extensions=0D=0A= mailing=20list,=20dime@ietf.org.
=0D= =0A
=0D=0A-Dave
=0D=0A=0D=0A
On=20Wed,= =20Mar=2012,=202008=20at=205:05=20AM,=20Suriyanarayanan=20B=20<= <= u>Suriya.B@aricent.com>=0D=0Awrote:=0D=0A

=0D=0ADear=20Sir= /Madam,=20
=0D=0A
=0D=0AI=20have=20an=20issue=20to=20be=20discussed=20= on=20Request=20for=20Comments:=203588.=0D= =0A
=0D=0A
=0D=0AIn= =20RFC=203588,=20Section=204.3.=20(=20Derived=20AVP=20Data=20Formats),=20= IPFilterRule=20and=0D=0AQoSFilterRule=20are=20Specifed=20as=20the=20de= rived=20data=20formats=20from=20the=20OctetString=0D=0AAVP=20Base=20forma= t.=20
=0D=0ABased=20on=20the=20definition=20given,=20shall=20we=20= consider=20the=20above=20two=20data=20formats=0D=0Ato=20be=20taken=20in= =20ABNF=20format.=20If=20so=20what=20is=20the=20ABNF=20grammar=20for=20th= at.=0D=0A
=0D=0A
=0D=0ASo=20Please=20confirm=20me=20the=20same=20as=20= soon=20as=20possible.=0D=0A
=0D=0A
=0D=0AThanks=20&=20Regards=20
= =0D=0ASuriya=20Narayanan=20B=20=0D=0A=0D=0A=0D=0A Software=0D=0AEng= ineer=20=0D=0A=0D= =0A A=20R=20I= =20C=20E=20N=20T=0D=0A=0D=0A=0D=0A&n= bsp;Plot=20No.5,=20Espee=20IT=20Park,=0D=0A3rd=20Floor,= =20=0D=0A=0D=0A Jawaharlal=20Nehru=20Salai= ,=0D=0AEkkattuthangal,=20=0D=0A=0D=0A Guindy,=0D=0AChennai=20–=20600097= =0D=0A=0D=0A=0D=0A Main:=20+91=2044=206621= 6369=0D=0A
=0D=0A=0D=0A=0D=0A=0D=0A
=0D=0A
=0D=0A
=0D=0A***********************=20 Aricent-Restri= cted=20 =20***********************=0D=0A=0D=0A=0D=0A=0D=0A"DISCLAIMER:=20This=20message=0D=0Ai= s=20proprietary=20to=20Aricent=20and=20is=20intended=20solely=20for=20the= =20use=20of=20
=0D=0Athe=20individual=20to=20whom=20it=20is=20addresse= d.=20It=20may=20contain=20privileged=20or=20confidential=0D=0Ainformation= =20and=20should=20not=20be=20
=0D=0Acirculated=20or=20used=20for=20any= =20purpose=20other=20than=20for=20what=20it=20is=20intended.=0D=0AIf=20yo= u=20have=20received=20this=20message=20in=20error,=20
=0D=0Aplease=20n= otify=20the=20originator=20immediately.=20If=20you=20are=20not=20the=20in= tended=20recipient,=0D=0Ayou=20are=20notified=20that=20you=20are=20strict= ly
=0D=0Aprohibited=20from=20using,=20copying,=20altering,=20or=20disc= losing=20the=20contents=20of=0D=0Athis=20message.=20Aricent=20accepts=20n= o=20responsibility=20for=20
=0D=0Aloss=20or=20damage=20arising=20from= =20the=20use=20of=20the=20information=20transmitted=20by=20this=0D=0Aemai= l=20including=20damage=20from=20virus."
=0D=0A=0D=0A

=0D=0A
=0D=0A***= ********************=20 Aricent-=20Confidential=20 =20*********= **************=0D=0A
"DISCLAIMER:=20This=20message=20is=20proprietary=20to=
=20Aricent=20and=20is=20intended=20solely=20for=20the=20use=20of=20=0Athe=
=20individual=20to=20whom=20it=20is=20addressed.=20It=20may=20contain=20p=
rivileged=20or=20confidential=20information=20and=20should=20not=20be=20=
=0Acirculated=20or=20used=20for=20any=20purpose=20other=20than=20for=20wh=
at=20it=20is=20intended.=20If=20you=20have=20received=20this=20message=20=
in=20error,=20=0Aplease=20notify=20the=20originator=20immediately.=20If=
=20you=20are=20not=20the=20intended=20recipient,=20you=20are=20notified=
=20that=20you=20are=20strictly=0Aprohibited=20from=20using,=20copying,=20=
altering,=20or=20disclosing=20the=20contents=20of=20this=20message.=20Ari=
cent=20accepts=20no=20responsibility=20for=20=0Aloss=20or=20damage=20aris=
ing=20from=20the=20use=20of=20the=20information=20transmitted=20by=20this=
=20email=20including=20damage=20from=20virus."=0A
<= /table> --=_alternative 004A42096525740A_=-- --===============0119351729== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0119351729==-- From dime-bounces@ietf.org Wed Mar 12 07:25:49 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B56928C6F0; Wed, 12 Mar 2008 07:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.836 X-Spam-Level: X-Spam-Status: No, score=-98.836 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, DEAR_SOMETHING=1.605, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HH6dn0mp4Byh; Wed, 12 Mar 2008 07:25:41 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F14B628C6C7; Wed, 12 Mar 2008 07:25:35 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FD503A6E39 for ; Wed, 12 Mar 2008 02:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fS4sMyChPtWN for ; Wed, 12 Mar 2008 02:04:49 -0700 (PDT) Received: from chemail01.che.aricent.com (unknown [125.17.107.171]) by core3.amsl.com (Postfix) with ESMTP id 864963A6E33 for ; Wed, 12 Mar 2008 02:04:48 -0700 (PDT) To: dime@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Build V655_10312005 October 31, 2005 Message-ID: From: Suriyanarayanan B Date: Wed, 12 Mar 2008 14:32:23 +0530 X-MIMETrack: Serialize by Router on Chemail01/CHE/HSS(Release 6.5.5|November 30, 2005) at 03/12/2008 02:32:29 PM, Serialize complete at 03/12/2008 02:32:29 PM X-Mailman-Approved-At: Wed, 12 Mar 2008 07:25:34 -0700 Subject: [Dime] Regarding IPFilterRule and QoSFilterRule AVP Data Formats in RFC3588 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0999632609==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============0999632609== Content-Type: multipart/alternative; boundary="=_alternative 0031A8896525740A_=" This is a multipart message in MIME format. --=_alternative 0031A8896525740A_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Dear=20Sir/Madam,=20=0D=0A=0D=0AI=20have=20an=20issue=20to=20be=20discuss= ed=20on=20Request=20for=20Comments(RFC):=203588.=20=0D=0A=0D=0AIn=20RFC= =203588,=20Section=204.3.=20(=20Derived=20AVP=20Data=20Formats),=20IPFilt= erRule=20and=20=0D=0AQoSFilterRule=20are=20Specifed=20as=20the=20derived= =20data=20formats=20from=20the=20=0D=0AOctetString=20AVP=20Base=20format.= =20=0D=0ABased=20on=20the=20definition=20given,=20shall=20we=20consider= =20the=20above=20two=20data=20=0D=0Aformats=20to=20be=20taken=20in=20ABNF= =20format.=20If=20so=20what=20is=20the=20ABNF=20grammar=20for=20=0D=0Atha= t.=20=0D=0A=0D=0ASo=20Please=20confirm=20me=20the=20same=20as=20soon=20as= =20possible.=20=0D=0A=0D=0AThanks=20&=20Regards=20=0D=0ASuriya=20Narayana= n=20B=20=0D=0A=20Software=20Engineer=20=0D=0A=20A=20R=20I=20C=20E=20N=20T= =20=0D=0A=20Plot=20No.5,=20Espee=20IT=20Park,=203rd=20Floor,=20=0D=0A=20J= awaharlal=20Nehru=20Salai,=20Ekkattuthangal,=20=0D=0A=20Guindy,=20Chennai= =20?=20600097=20=0D=0A=20Main:=20+91=2044=2066216369=20=0D=0A=0D=0A=0D=0A= =0D=0A***********************=20=20Aricent-=20Confidential=20=20=20******= *****************=0D=0A"DISCLAIMER:=20This=20message=20is=20proprietary= =20to=20Aricent=20and=20is=20intended=20solely=20for=20the=20use=20of=20= =0Athe=20individual=20to=20whom=20it=20is=20addressed.=20It=20may=20conta= in=20privileged=20or=20confidential=20information=20and=20should=20not=20= be=20=0Acirculated=20or=20used=20for=20any=20purpose=20other=20than=20for= =20what=20it=20is=20intended.=20If=20you=20have=20received=20this=20messa= ge=20in=20error,=20=0Aplease=20notify=20the=20originator=20immediately.= =20If=20you=20are=20not=20the=20intended=20recipient,=20you=20are=20notif= ied=20that=20you=20are=20strictly=0Aprohibited=20from=20using,=20copying,= =20altering,=20or=20disclosing=20the=20contents=20of=20this=20message.=20= Aricent=20accepts=20no=20responsibility=20for=20=0Aloss=20or=20damage=20a= rising=20from=20the=20use=20of=20the=20information=20transmitted=20by=20t= his=20email=20including=20damage=20from=20virus."=0A --=_alternative 0031A8896525740A_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0D=0A
Dear=20Sir/Madam,= =0D=0A
= =0D=0A
=0D=0AI=20have=20an=20issue=20to=20be=20discussed=20on=20Req= uest=20for=20Comments(RFC):=203588.=0D=0A
=0D=0A
=0D=0AIn=20RFC=20= 3588,=20Section=204.3.=20(=20Derived=20AVP=20Data=20Formats),=20IPFilterR= ule=20and=0D=0AQoSFilterRule=20are=20Specifed=20as=20the=20derived=20d= ata=20formats=20from=20the=20OctetString=0D=0AAVP=20Base=20format.=20=
=0D=0ABased=20on=20the=20definition=20given,=20shall=20we=20consider= =20the=20above=20two=20data=20formats=0D=0Ato=20be=20taken=20in=20ABNF=20= format.=20If=20so=20what=20is=20the=20ABNF=20grammar=20for=20that.= =0D=0A
= =0D=0A
=0D=0ASo=20Please=20confirm=20me=20the=20same=20as=20soon=20as= =20possible.=0D=0A
=0D=0A
=0D=0AThanks=20&=20Regards=20
=0D=0ASu= riya=20Narayanan=20B=20=0D=0A=0D=0A=0D=0A Software=0D=0AEngineer=20=0D=0A=0D=0A
"DISCLAIMER:=
=20This=20message=20is=20proprietary=20to=20Aricent=20=20and=20is=20inten=
ded=20solely=20for=20the=20use=20of=20=0Athe=20individual=20to=20whom=20i=
t=20is=20addressed.=20It=20may=20contain=20privileged=20or=20confidential=
=20information=20and=20should=20not=20be=20=0Acirculated=20or=20used=20fo=
r=20any=20purpose=20other=20than=20for=20what=20it=20is=20intended.=20If=
=20you=20have=20received=20this=20message=20in=20error,=20=0Aplease=20not=
ify=20the=20originator=20immediately.=20If=20you=20are=20not=20the=20inte=
nded=20recipient,=20you=20are=20notified=20that=20you=20are=20strictly=0A=
prohibited=20from=20using,=20copying,=20altering,=20or=20disclosing=20the=
=20contents=20of=20this=20message.=20Aricent=20accepts=20no=20responsibil=
ity=20for=20=0Aloss=20or=20damage=20arising=20from=20the=20use=20of=20the=
=20information=20transmitted=20by=20this=20email=20including=20damage=20f=
rom=20virus."=0A
 A=20R=20I=20C=20E= =20N=20T=0D=0A=0D=0A=0D=0A Plot= =20No.5,=20Espee=20IT=20Park,=0D=0A3rd=20Floor,=20=0D=0A=0D=0A Jawaharlal=20Nehru=20Salai,=0D=0AE= kkattuthangal,=20=0D=0A=0D=0A Guindy,=0D=0AChennai=20–=20600097=0D=0A=0D=0A=0D=0A Main:=20+91=2044=2066216369=0D=0A=0D=0A=0D=0A=0D=0A

=0D=0A
=0D=0A*= **********************=20 Aricent-=20Confidential=20 =20*******= ****************=0D=0A
"DISCLAIMER:=20This=20message=20is=20proprietary=20to=
=20Aricent=20and=20is=20intended=20solely=20for=20the=20use=20of=20=0Athe=
=20individual=20to=20whom=20it=20is=20addressed.=20It=20may=20contain=20p=
rivileged=20or=20confidential=20information=20and=20should=20not=20be=20=
=0Acirculated=20or=20used=20for=20any=20purpose=20other=20than=20for=20wh=
at=20it=20is=20intended.=20If=20you=20have=20received=20this=20message=20=
in=20error,=20=0Aplease=20notify=20the=20originator=20immediately.=20If=
=20you=20are=20not=20the=20intended=20recipient,=20you=20are=20notified=
=20that=20you=20are=20strictly=0Aprohibited=20from=20using,=20copying,=20=
altering,=20or=20disclosing=20the=20contents=20of=20this=20message.=20Ari=
cent=20accepts=20no=20responsibility=20for=20=0Aloss=20or=20damage=20aris=
ing=20from=20the=20use=20of=20the=20information=20transmitted=20by=20this=
=20email=20including=20damage=20from=20virus."=0A
<= /table> --=_alternative 0031A8896525740A_=-- --===============0999632609== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0999632609==-- From dime-bounces@ietf.org Wed Mar 12 07:25:52 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88A9028C6F2; Wed, 12 Mar 2008 07:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.835 X-Spam-Level: X-Spam-Status: No, score=-98.835 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, DEAR_SOMETHING=1.605, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KrBTgizWfSH; Wed, 12 Mar 2008 07:25:43 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 283C328C6E5; Wed, 12 Mar 2008 07:25:36 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CFEE3A6E31 for ; Wed, 12 Mar 2008 02:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mP+8xfB-iTSG for ; Wed, 12 Mar 2008 02:11:25 -0700 (PDT) Received: from chemail01.che.aricent.com (unknown [125.17.107.171]) by core3.amsl.com (Postfix) with ESMTP id 2F8063A6A3B for ; Wed, 12 Mar 2008 02:11:25 -0700 (PDT) To: dime@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Build V655_10312005 October 31, 2005 Message-ID: From: Suriyanarayanan B Date: Wed, 12 Mar 2008 14:39:00 +0530 X-MIMETrack: Serialize by Router on Chemail01/CHE/HSS(Release 6.5.5|November 30, 2005) at 03/12/2008 02:39:05 PM, Serialize complete at 03/12/2008 02:39:05 PM X-Mailman-Approved-At: Wed, 12 Mar 2008 07:25:34 -0700 Subject: [Dime] Regarding IPFilterRule and QoSFilterRule AVP Data Formats in RFC 3588 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0474086679==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============0474086679== Content-Type: multipart/alternative; boundary="=_alternative 003243B66525740A_=" This is a multipart message in MIME format. --=_alternative 003243B66525740A_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Dear=20Sir/Madam,=0D=0A=0D=0AI=20have=20an=20issue=20to=20be=20discussed= =20on=20Request=20for=20Comments:=203588.=0D=0A=0D=0AIn=20RFC=203588,=20S= ection=204.3.=20(=20Derived=20AVP=20Data=20Formats),=20IPFilterRule=20and= =20=0D=0AQoSFilterRule=20are=20Specifed=20as=20the=20derived=20data=20for= mats=20from=20the=20=0D=0AOctetString=20AVP=20Base=20format.=20=0D=0ABase= d=20on=20the=20definition=20given,=20shall=20we=20consider=20the=20above= =20two=20data=20=0D=0Aformats=20to=20be=20taken=20in=20ABNF=20format.=20I= f=20so=20what=20is=20the=20ABNF=20grammar=20for=20=0D=0Athat.=0D=0A=0D=0A= So=20Please=20confirm=20me=20the=20same=20as=20soon=20as=20possible.=0D= =0A=0D=0AThanks=20&=20Regards=0D=0ASuriya=20Narayanan=20B=0D=0A=0D=0A=20S= oftware=20Engineer=20=0D=0A=20A=20R=20I=20C=20E=20N=20T=20=0D=0A=20Plot= =20No.5,=20Espee=20IT=20Park,=203rd=20Floor,=20=0D=0A=20Jawaharlal=20Nehr= u=20Salai,=20Ekkattuthangal,=20=0D=0A=20Guindy,=20Chennai=20?=20600097=20= =0D=0A=20Main:=20+91=2044=2066216369=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A*= **********************=20=20Aricent-=20Confidential=20=20=20*************= **********=0D=0A"DISCLAIMER:=20This=20message=20is=20proprietary=20to=20A= ricent=20and=20is=20intended=20solely=20for=20the=20use=20of=20=0Athe=20i= ndividual=20to=20whom=20it=20is=20addressed.=20It=20may=20contain=20privi= leged=20or=20confidential=20information=20and=20should=20not=20be=20=0Aci= rculated=20or=20used=20for=20any=20purpose=20other=20than=20for=20what=20= it=20is=20intended.=20If=20you=20have=20received=20this=20message=20in=20= error,=20=0Aplease=20notify=20the=20originator=20immediately.=20If=20you= =20are=20not=20the=20intended=20recipient,=20you=20are=20notified=20that= =20you=20are=20strictly=0Aprohibited=20from=20using,=20copying,=20alterin= g,=20or=20disclosing=20the=20contents=20of=20this=20message.=20Aricent=20= accepts=20no=20responsibility=20for=20=0Aloss=20or=20damage=20arising=20f= rom=20the=20use=20of=20the=20information=20transmitted=20by=20this=20emai= l=20including=20damage=20from=20virus."=0A --=_alternative 003243B66525740A_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0D=0A
Dear=20Sir/Madam,= =0D=0A
=0D=0A
I=20have=20an= =20issue=20to=20be=20discussed=20on=20Request=0D=0Afor=20Comments:=203= 588.=0D=0A
=0D=0A
In=20RFC=203588,=20Section=204.3.=20(=20Derived=0D=0AAVP=20Data=20Format= s),=20IPFilterRule=20and=20QoSFilterRule=20are=20Specifed=20as=20the=20derived=0D=0Adata=20formats=20from=20the=20OctetString=20AVP=20Base=20fo= rmat.=20
=0D=0ABased=20on=20the=20definition=20given,=20shall=20we= =20consider=20the=20above=20two=20data=20formats=0D=0Ato=20be=20taken=20i= n=20ABNF=20format.=20If=20so=20what=20is=20the=20ABNF=20grammar=20for=20t= hat.=0D=0A
=0D=0A
So= =20Please=20confirm=20me=20the=20same=20as=20soon=0D=0Aas=20possible.=0D=0A
=0D=0A
Thanks=20&a= mp;=20Regards=0D=0A
Suri= ya=20Narayanan=20B=0D=0A
=0D=0A=0D=0A=0D=0A Software=0D=0AEngineer=20=0D=0A=0D=0A
 A=20R=20I=20C=20E=20N=20T=0D=0A=0D=0A=0D=0A Plot=20No.5,=20Espee=20IT= =20Park,=0D=0A3rd=20Floor,=20= =0D=0A=0D=0A Jawaharlal=20Nehru=20Salai,=0D=0AEkkattuthangal,=20=0D=0A=0D=0A Guindy,=0D=0AChennai=20–=20600097=0D=0A=0D=0A=0D=0A Main:=20+91=2044=2066216369=0D=0A
=0D=0A=0D=0A=0D=0A
=0D=0A

=0D=0A
=0D=0A***********************=20&nbs= p;Aricent-=20Confidential=20 =20***********************=0D=0A= 
"DISCLAIM=
ER:=20This=20message=20is=20proprietary=20to=20Aricent=20and=20is=20inten=
ded=20solely=20for=20the=20use=20of=20=0Athe=20individual=20to=20whom=20i=
t=20is=20addressed.=20It=20may=20contain=20privileged=20or=20confidential=
=20information=20and=20should=20not=20be=20=0Acirculated=20or=20used=20fo=
r=20any=20purpose=20other=20than=20for=20what=20it=20is=20intended.=20If=
=20you=20have=20received=20this=20message=20in=20error,=20=0Aplease=20not=
ify=20the=20originator=20immediately.=20If=20you=20are=20not=20the=20inte=
nded=20recipient,=20you=20are=20notified=20that=20you=20are=20strictly=0A=
prohibited=20from=20using,=20copying,=20altering,=20or=20disclosing=20the=
=20contents=20of=20this=20message.=20Aricent=20accepts=20no=20responsibil=
ity=20for=20=0Aloss=20or=20damage=20arising=20from=20the=20use=20of=20the=
=20information=20transmitted=20by=20this=20email=20including=20damage=20f=
rom=20virus."=0A
--=_alternative 003243B66525740A_=-- --===============0474086679== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0474086679==-- From dime-bounces@ietf.org Wed Mar 12 08:05:27 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E75C628C93A; Wed, 12 Mar 2008 08:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.036 X-Spam-Level: X-Spam-Status: No, score=-100.036 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_62=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHC8P0JGhHBG; Wed, 12 Mar 2008 08:05:27 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26BAA28C874; Wed, 12 Mar 2008 08:02:31 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91F6C28C84C; Wed, 12 Mar 2008 08:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUxEPENMq+-3; Wed, 12 Mar 2008 08:02:27 -0700 (PDT) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by core3.amsl.com (Postfix) with ESMTP id 93B5328C83F; Wed, 12 Mar 2008 08:00:36 -0700 (PDT) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama500.ecl.ntt.co.jp (8.14.2/8.14.2) with ESMTP id m2CEw2jw004855; Wed, 12 Mar 2008 23:58:02 +0900 (JST) Received: from mfs6.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id C098B6BFB; Wed, 12 Mar 2008 23:58:02 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (eclscan2.m.ecl.ntt.co.jp [129.60.5.68]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id B6FCC6B9E; Wed, 12 Mar 2008 23:58:02 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m2CEw2T6000528; Wed, 12 Mar 2008 23:58:02 +0900 (JST) Received: from imh.m.ecl.ntt.co.jp (imh0.m.ecl.ntt.co.jp [129.60.5.146]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m2CEw2T0000519; Wed, 12 Mar 2008 23:58:02 +0900 (JST) Received: from [127.0.0.1] ([129.60.13.7]) by imh.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m2CEw0MM005234; Wed, 12 Mar 2008 23:58:01 +0900 (JST) Message-ID: <47D7F019.7040802@lab.ntt.co.jp> Date: Thu, 13 Mar 2008 00:00:41 +0900 From: Hiroaki Sato User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Bernard_Aboba@hotmail.com References: <47D6F9D3.1000905@lab.ntt.co.jp> <47D70804.8070704@gmx.net> <47D7E09D.8010307@lab.ntt.co.jp> In-Reply-To: <47D7E09D.8010307@lab.ntt.co.jp> Cc: christian.jacquenet@francetelecom.com, thayashi@digitalforest.co.jp, radiusext@ops.ietf.org, mboned@ietf.org, dime@ietf.org Subject: Re: [Dime] [ANCP] mboned multiaa-framework reflecting the ancp framework draft, request for review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Bernard and Hannes, Our response is listed in the mboned archive but I don't see it RADEXT:it may be rejected. Please see http://www.ietf.org/mail-archive/web/mboned/current/msg00375.html I'll resend it to RADEXT ML. Should I send it to Diameter ML, too? Thank you, Hiroaki > Thank you for telling me. > We reflected RADEXT comments recieved from Alan. It seems like > http://ops.ietf.org/lists/radiusext/2007/msg00659.html. > And I replied to radiusext@ops.ietf.org on 2007/11/26. > Actually, most of comments were reflected to -05 version. > I'll check it once more. > > Hiroaki > >> I agree with Hannes. >> >> So far I have not seen any response on the RADEXT WG mailing list to >> the review of this document: >> http://ops.ietf.org/lists/radiusext/2007/msg00659.html >> >> -------------------------------------------------- >> From: "Hannes Tschofenig" >> Sent: Tuesday, March 11, 2008 3:30 PM >> To: >> Cc: "Hiroaki Sato" ; "Romascanu, Dan >> (Dan)" ; ; >> ; ; >> >> Subject: Re: [ANCP] mboned multiaa-framework reflecting the ancp >> framework draft, request for review >> >>> Scott Bradner asked us a while ago to review your AAA framework draft. >>> http://www.ops.ietf.org/lists/radiusext/2007/msg00528.html >>> >>> We at DIME did an initial review. You can find it here: >>> http://www.ietf.org/mail-archive/web/dime/current/msg02007.html >>> http://www.ietf.org/mail-archive/web/dime/current/msg01912.html >>> http://www.ietf.org/mail-archive/web/dime/current/msg01899.html >>> >>> I recall that there were also reviews from the RADEXT working group. >>> >>> I don't see these reviews being addressed. >>> >>> I am also puzzled why the DIME and the RADEXT working group aren't >>> get consulted more involved given that this is clearly about the AAA >>> interworking. >>> >>> Ciao >>> Hannes >>> >>> >>> Hiroaki Sato wrote: >>>> Hi all, >>>> >>>> We, the authors of draft-ietf-mboned-multiaaa-framework-06.txt, revised >>>> our draft and some items refer to the ancp framework draft. >>>> So, we'd like to request for you to review our draft and please comment >>>> on it. >>>> >>>> Major changes include: >>>> -two levels of accounting information (start/stop only and plus volume) >>>> -acconting for fast channel change (information merging) >>>> -QoS downgrade (admission control) >>>> >>>> thank you, >>>> Hiroaki >>>> >>>> --- >>>> ************************************ >>>> NTT Network Service Systems Lab. >>>> Hiroaki Sato >>>> TEL:0422-59-4683 (+81-422-59-4683) >>>> FAX:0422-59-5636 (+81-422-59-5636) >>>> ************************************ >>>> >>>> _______________________________________________ >>>> ANCP mailing list >>>> ANCP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ancp >>>> >>> >>> >> >> > > -- ************************************ NTT Network Service Systems Lab. Hiroaki Sato TEL:0422-59-4683 (+81-422-59-4683) FAX:0422-59-5636 (+81-422-59-5636) ************************************ _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 12 08:10:15 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7628A3A6E99; Wed, 12 Mar 2008 08:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.15 X-Spam-Level: X-Spam-Status: No, score=-100.15 tagged_above=-999 required=5 tests=[AWL=-0.313, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_62=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdijMxPJUpHh; Wed, 12 Mar 2008 08:10:11 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6123428C858; Wed, 12 Mar 2008 08:07:30 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A37128C851 for ; Wed, 12 Mar 2008 08:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Szh6oWte+MQr for ; Wed, 12 Mar 2008 08:07:24 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D1C3928C86F for ; Wed, 12 Mar 2008 08:05:24 -0700 (PDT) Received: (qmail invoked by alias); 12 Mar 2008 15:03:05 -0000 Received: from dhcp-1575.ietf71.ietf.org (EHLO [130.129.21.117]) [130.129.21.117] by mail.gmx.net (mp046) with SMTP; 12 Mar 2008 16:03:05 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/ylbxfXGvyCan/luy7tlPyymSZT9Y0nUCdg9/7uK UmSLJeyBopxgEi Message-ID: <47D7F0A7.3030408@gmx.net> Date: Wed, 12 Mar 2008 17:03:03 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Hiroaki Sato References: <47D6F9D3.1000905@lab.ntt.co.jp> <47D70804.8070704@gmx.net> <47D7E09D.8010307@lab.ntt.co.jp> <47D7F019.7040802@lab.ntt.co.jp> In-Reply-To: <47D7F019.7040802@lab.ntt.co.jp> X-Y-GMX-Trusted: 0 Cc: christian.jacquenet@francetelecom.com, Bernard_Aboba@hotmail.com, thayashi@digitalforest.co.jp, radiusext@ops.ietf.org, mboned@ietf.org, dime@ietf.org Subject: Re: [Dime] [ANCP] mboned multiaa-framework reflecting the ancp framework draft, request for review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Are you subscribed to DIME or RADEXT? If not, then it might have just disappeared with the rest of the spam Hiroaki Sato wrote: > Hi Bernard and Hannes, > > Our response is listed in the mboned archive but I don't see it > RADEXT:it may be rejected. > Please see > http://www.ietf.org/mail-archive/web/mboned/current/msg00375.html > I'll resend it to RADEXT ML. > Should I send it to Diameter ML, too? > > Thank you, > Hiroaki > >> Thank you for telling me. >> We reflected RADEXT comments recieved from Alan. It seems like >> http://ops.ietf.org/lists/radiusext/2007/msg00659.html. >> And I replied to radiusext@ops.ietf.org on 2007/11/26. >> Actually, most of comments were reflected to -05 version. >> I'll check it once more. >> >> Hiroaki >> >>> I agree with Hannes. >>> >>> So far I have not seen any response on the RADEXT WG mailing list to >>> the review of this document: >>> http://ops.ietf.org/lists/radiusext/2007/msg00659.html >>> >>> -------------------------------------------------- >>> From: "Hannes Tschofenig" >>> Sent: Tuesday, March 11, 2008 3:30 PM >>> To: >>> Cc: "Hiroaki Sato" ; "Romascanu, Dan >>> (Dan)" ; ; >>> ; >>> ; >>> Subject: Re: [ANCP] mboned multiaa-framework reflecting the ancp >>> framework draft, request for review >>> >>>> Scott Bradner asked us a while ago to review your AAA framework draft. >>>> http://www.ops.ietf.org/lists/radiusext/2007/msg00528.html >>>> >>>> We at DIME did an initial review. You can find it here: >>>> http://www.ietf.org/mail-archive/web/dime/current/msg02007.html >>>> http://www.ietf.org/mail-archive/web/dime/current/msg01912.html >>>> http://www.ietf.org/mail-archive/web/dime/current/msg01899.html >>>> >>>> I recall that there were also reviews from the RADEXT working group. >>>> >>>> I don't see these reviews being addressed. >>>> >>>> I am also puzzled why the DIME and the RADEXT working group aren't >>>> get consulted more involved given that this is clearly about the >>>> AAA interworking. >>>> >>>> Ciao >>>> Hannes >>>> >>>> >>>> Hiroaki Sato wrote: >>>>> Hi all, >>>>> >>>>> We, the authors of draft-ietf-mboned-multiaaa-framework-06.txt, >>>>> revised >>>>> our draft and some items refer to the ancp framework draft. >>>>> So, we'd like to request for you to review our draft and please >>>>> comment >>>>> on it. >>>>> >>>>> Major changes include: >>>>> -two levels of accounting information (start/stop only and plus >>>>> volume) >>>>> -acconting for fast channel change (information merging) >>>>> -QoS downgrade (admission control) >>>>> >>>>> thank you, >>>>> Hiroaki >>>>> >>>>> --- >>>>> ************************************ >>>>> NTT Network Service Systems Lab. >>>>> Hiroaki Sato >>>>> TEL:0422-59-4683 (+81-422-59-4683) >>>>> FAX:0422-59-5636 (+81-422-59-5636) >>>>> ************************************ >>>>> >>>>> _______________________________________________ >>>>> ANCP mailing list >>>>> ANCP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ancp >>>>> >>>> >>>> >>> >>> >> >> > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 12 08:15:03 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D58F28C7A5; Wed, 12 Mar 2008 08:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.237 X-Spam-Level: X-Spam-Status: No, score=-100.237 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1azXrx7OScbS; Wed, 12 Mar 2008 08:14:58 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 653E128C775; Wed, 12 Mar 2008 08:14:56 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E86328C780 for ; Wed, 12 Mar 2008 08:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cby2sDfD3cpP for ; Wed, 12 Mar 2008 08:14:50 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [61.246.186.17]) by core3.amsl.com (Postfix) with ESMTP id 6FCED28C7E4 for ; Wed, 12 Mar 2008 08:14:31 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id m2CEwgIg011702 for ; Wed, 12 Mar 2008 20:28:42 +0530 Received: from sandesh.gur.aricent.com (sandesh [10.203.142.21]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id m2CEwewx011672; Wed, 12 Mar 2008 20:28:41 +0530 Importance: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 From: Preeti Shandilya To: ? =?ISO-8859-1?Q?=CF=3F=C1?= Date: Wed, 12 Mar 2008 20:42:00 +0530 Message-ID: X-Mailer: Lotus Domino Web Server Build V655_10312005 October 31, 2005 X-MIMETrack: Serialize by Notes Server on Presidency/HSS(Build V655_10312005|October 31, 2005) at 03/12/2008 08:42:00 PM, Serialize complete at 03/12/2008 08:42:00 PM, Itemize by Notes Server on Presidency/HSS(Build V655_10312005|October 31, 2005) at 03/12/2008 08:42:00 PM, Serialize by Router on Sandesh/HSS(Release 6.5.5|November 30, 2005) at 12/03/2008 08:47:33 PM, Serialize complete at 12/03/2008 08:47:33 PM MIME-Version: 1.0 Cc: dime@ietf.org Subject: Re: [Dime] Transient Failures in DCCA X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1305925129==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1305925129== Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ISO-8859-1"
Hi=20!
 
Server=20should=20not= =20wait=20to=20get=20terminate=20request=20from=20client=20after=20sendin= g=20CCA=20with=20result=20code=204010=20or= =204011=20or=204012.=20The=20reason=20is=20that=20client=20shall= =20clear=20the=20session=20contexts=20,=20on=20receiving=20any=20of=20the= se=20result=20codes=20from=20server=20and=20then=20it=20shall=20never=20s= end=20terminate=20request
 
regards
pr= eeti
-----dime-bounces@ietf.org=20wrote:= =20-----

To:=20dime@ietf.org
From:=20?=CF?=C1=20&= lt;rigir2000@mail.ru>
Sent=20by:=20dime-bounces@ietf.org
Date:= =2002/29/2008=2001:31PM
Subject:=20[Dime]=20Transient=20Failures=20in= =20DCCA

Hello,
Please,=20gi= ve=20the=20comments=20upon=20 RFC=204006=20on=20next=20conclusion:When=20server=20in=20CCA=20Update=20return=20Result_Code=20=3D=204010= =20or=204011=20or=204012.
Server=20MUST=20 or=20not=20MUST=20wait= =20from=20client=20CCR=20Terminate?
Thank=20You.


__________= _____________________________________
DiME=20mailing=20list
DiME@ie= tf.org
https://www.ietf.org/mailman/listinfo/dime


*****Aricent-Unclassified=20*****=3D=0D=0A
--===============1305925129== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1305925129==-- From dime-bounces@ietf.org Wed Mar 12 09:54:11 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E286028C6B6; Wed, 12 Mar 2008 09:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.958 X-Spam-Level: X-Spam-Status: No, score=-99.958 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_62=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjkI24RdnekS; Wed, 12 Mar 2008 09:54:06 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 474E43A6EEC; Wed, 12 Mar 2008 09:54:05 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C41773A6EBF; Wed, 12 Mar 2008 09:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opch9vd-lQEQ; Wed, 12 Mar 2008 09:53:58 -0700 (PDT) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by core3.amsl.com (Postfix) with ESMTP id 05F2C3A693D; Wed, 12 Mar 2008 09:53:57 -0700 (PDT) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama500.ecl.ntt.co.jp (8.14.2/8.14.2) with ESMTP id m2CGpRZo008999; Thu, 13 Mar 2008 01:51:27 +0900 (JST) Received: from mfs5.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 8382C63EE; Thu, 13 Mar 2008 01:51:27 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (eclscan2.m.ecl.ntt.co.jp [129.60.5.68]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 7AF8563ED; Thu, 13 Mar 2008 01:51:27 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m2CGpRkD011892; Thu, 13 Mar 2008 01:51:27 +0900 (JST) Received: from imh.m.ecl.ntt.co.jp (imh0.m.ecl.ntt.co.jp [129.60.5.146]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m2CGpQZF011888; Thu, 13 Mar 2008 01:51:26 +0900 (JST) Received: from [127.0.0.1] ([129.60.13.7]) by imh.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m2CGpP3A010972; Thu, 13 Mar 2008 01:51:26 +0900 (JST) Message-ID: <47D80AAE.4030509@lab.ntt.co.jp> Date: Thu, 13 Mar 2008 01:54:06 +0900 From: Hiroaki Sato User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Hannes Tschofenig References: <47D6F9D3.1000905@lab.ntt.co.jp> <47D70804.8070704@gmx.net> <47D7E09D.8010307@lab.ntt.co.jp> <47D7F019.7040802@lab.ntt.co.jp> <47D7F0A7.3030408@gmx.net> In-Reply-To: <47D7F0A7.3030408@gmx.net> Cc: christian.jacquenet@francetelecom.com, Bernard_Aboba@hotmail.com, thayashi@digitalforest.co.jp, radiusext@ops.ietf.org, mboned@ietf.org, dime@ietf.org Subject: Re: [Dime] [ANCP] mboned multiaa-framework reflecting the ancp framework draft, request for review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Actually, no. Thank you for your advice. > Are you subscribed to DIME or RADEXT? > If not, then it might have just disappeared with the rest of the spam > > Hiroaki Sato wrote: >> Hi Bernard and Hannes, >> >> Our response is listed in the mboned archive but I don't see it >> RADEXT:it may be rejected. >> Please see >> http://www.ietf.org/mail-archive/web/mboned/current/msg00375.html >> I'll resend it to RADEXT ML. >> Should I send it to Diameter ML, too? >> >> Thank you, >> Hiroaki >> >>> Thank you for telling me. >>> We reflected RADEXT comments recieved from Alan. It seems like >>> http://ops.ietf.org/lists/radiusext/2007/msg00659.html. >>> And I replied to radiusext@ops.ietf.org on 2007/11/26. >>> Actually, most of comments were reflected to -05 version. >>> I'll check it once more. >>> >>> Hiroaki >>> >>>> I agree with Hannes. >>>> >>>> So far I have not seen any response on the RADEXT WG mailing list to >>>> the review of this document: >>>> http://ops.ietf.org/lists/radiusext/2007/msg00659.html >>>> >>>> -------------------------------------------------- >>>> From: "Hannes Tschofenig" >>>> Sent: Tuesday, March 11, 2008 3:30 PM >>>> To: >>>> Cc: "Hiroaki Sato" ; "Romascanu, Dan >>>> (Dan)" ; ; >>>> ; >>>> ; >>>> Subject: Re: [ANCP] mboned multiaa-framework reflecting the ancp >>>> framework draft, request for review >>>> >>>>> Scott Bradner asked us a while ago to review your AAA framework draft. >>>>> http://www.ops.ietf.org/lists/radiusext/2007/msg00528.html >>>>> >>>>> We at DIME did an initial review. You can find it here: >>>>> http://www.ietf.org/mail-archive/web/dime/current/msg02007.html >>>>> http://www.ietf.org/mail-archive/web/dime/current/msg01912.html >>>>> http://www.ietf.org/mail-archive/web/dime/current/msg01899.html >>>>> >>>>> I recall that there were also reviews from the RADEXT working group. >>>>> >>>>> I don't see these reviews being addressed. >>>>> >>>>> I am also puzzled why the DIME and the RADEXT working group aren't >>>>> get consulted more involved given that this is clearly about the >>>>> AAA interworking. >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> >>>>> Hiroaki Sato wrote: >>>>>> Hi all, >>>>>> >>>>>> We, the authors of draft-ietf-mboned-multiaaa-framework-06.txt, >>>>>> revised >>>>>> our draft and some items refer to the ancp framework draft. >>>>>> So, we'd like to request for you to review our draft and please >>>>>> comment >>>>>> on it. >>>>>> >>>>>> Major changes include: >>>>>> -two levels of accounting information (start/stop only and plus >>>>>> volume) >>>>>> -acconting for fast channel change (information merging) >>>>>> -QoS downgrade (admission control) >>>>>> >>>>>> thank you, >>>>>> Hiroaki >>>>>> >>>>>> --- >>>>>> ************************************ >>>>>> NTT Network Service Systems Lab. >>>>>> Hiroaki Sato >>>>>> TEL:0422-59-4683 (+81-422-59-4683) >>>>>> FAX:0422-59-5636 (+81-422-59-5636) >>>>>> ************************************ >>>>>> >>>>>> _______________________________________________ >>>>>> ANCP mailing list >>>>>> ANCP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ancp >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > > -- ************************************ NTT Network Service Systems Lab. Hiroaki Sato TEL:0422-59-4683 (+81-422-59-4683) FAX:0422-59-5636 (+81-422-59-5636) ************************************ _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 12 11:58:18 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DC6328C37E; Wed, 12 Mar 2008 11:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.255 X-Spam-Level: X-Spam-Status: No, score=-100.255 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeJ8cSGmh8lw; Wed, 12 Mar 2008 11:58:16 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2D473A68BE; Wed, 12 Mar 2008 11:58:16 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 114FB3A68BE for ; Wed, 12 Mar 2008 11:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dh8wK37EA2OR for ; Wed, 12 Mar 2008 11:58:10 -0700 (PDT) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by core3.amsl.com (Postfix) with ESMTP id D2EBB3A6814 for ; Wed, 12 Mar 2008 11:58:09 -0700 (PDT) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama500.ecl.ntt.co.jp (8.14.2/8.14.2) with ESMTP id m2CItjAd014127; Thu, 13 Mar 2008 03:55:45 +0900 (JST) Received: from mfs6.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 05F3B6BFB; Thu, 13 Mar 2008 03:55:45 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (eclscan2.m.ecl.ntt.co.jp [129.60.5.68]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id EF0126B9E; Thu, 13 Mar 2008 03:55:44 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m2CItin5022639; Thu, 13 Mar 2008 03:55:44 +0900 (JST) Received: from imh.m.ecl.ntt.co.jp (imh0.m.ecl.ntt.co.jp [129.60.5.146]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m2CIti4G022636; Thu, 13 Mar 2008 03:55:44 +0900 (JST) Received: from [127.0.0.1] ([129.60.13.7]) by imh.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m2CItgOm016970; Thu, 13 Mar 2008 03:55:43 +0900 (JST) Message-ID: <47D827D0.1030507@lab.ntt.co.jp> Date: Thu, 13 Mar 2008 03:58:24 +0900 From: Hiroaki Sato User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: radiusext@ops.ietf.org References: <46CAB399.1070307@deployingradius.com> <474A2912.20702@lab.ntt.co.jp> In-Reply-To: <474A2912.20702@lab.ntt.co.jp> Cc: tsunemasa@gmail.com, dime@ietf.org, christian.jacquenet@francetelecom.com, ohta.hiroshi@lab.ntt.co.jp Subject: Re: [Dime] Request for review of "AAA Framework for Multicasting" X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi all, I'm resending the previous response to RADEXT comments for our draft,draft-ietf-mboned-multiaaa-framework-xx, because it may be dropped. Thank you, Hiroaki > Mr Dekok, > > Thank you for your detailed feedback on the "AAA Framework for > Multicasting" draft. Last week we submitted a revised version of the > draft reflecting many of your suggestions. > http://www.ietf.org/internet-drafts/draft-ietf-mboned-multiaaa-framework-05.txt > > > A summary of changes: > * In section 4.1 we broke explanations down into the different use cases > of multiple CP - multiple NSPs, single to multiple, etc. The most > general case multiple CPs to mulitple NSPs was described as a time > sequence and the other cases where compared to this most general case. > > * Section 4.2 elaboration of NSP assigned userID vs CP assigned userID > was added. > > * In sections 4.3, 4.4 and 4.5 were largely rewritten to clarify AAA > characteristics specific to multicasting > > Below we respond to your feedback inline: > > > (1) I'm not sure why Section 2 defines the terms Accounting, > > Authentication, and Authorization. The document is already discussing > > AAA issues, so familiarity with the three A's should be assumed. > > > > Perhaps the intent was to give examples of how AAA would be used in > > this scenario? > > Indeed, the intent is to give multicast-inferred examples so we have > decided to leave these definitions. > > > (2) Section 4.1 is titled "Framework for multicast AAA". This may lead > > someone to conclude that the AAA protocol is being multicast. I don't > > think that's correct. > > > Agreed. We propose to rename the section "AAA Framework in > Multicast-Enabled Envrionments" in a future revision. > > > (3)The diagram in that section appears to confuse the AAA process > with the > > later multicast data. My understanding is that the request/response for > > AAA is unicast, and the data that is being accessed is then sent via > > multicast. > > > We removed the label "multicast data" as suggested. > > > > > (4) Perhaps a time-sequence diagram would be useful, to replace the > > diagram in Section 4.1. > > (4) The text in 4.1 is also awkward. It contains a series of > overlapping > > conditionals for setting behavior. The text should be expanded to > > describe specific scenarios in detail from start to finish, rather than > > discussing multiple scenarios simultaneously. Adding a time-sequence > > diagram for each scenario would be useful, too. > > > > 4.1 was reorganized and rewritten to describe the following cases: > multiple CPs connected multiple NSPS, multiple CPs to a single NSP, > single CP to multiple NSPs and single CP to multiple NSPs. The most > general case multiple CPs to mulitple NSPs was described as a time > sequence. Then the other cases were compared to the general case. > > > > (5) Section 4.2 Multiple User IDs is confusing. In AAA, each user > id is > > treated as a separate user. This document should avoid the term "user > > id", as it is easy to confuse with the term "user". Instead, maybe > > "access identifier" could be used. The definition could be added to > > Section 2.1. > > > > We revised this section to better explain what we mean by multiple UIDs > and distinguish between NSP assigned userIDs and CP assigned userIDs. > Security considerations about handling the IDs are also addressed. > > > (6) The relationships between the terms (1:N, M:N, etc.) should also be > > included in the definitions in Section 2.1. This lets the reader > > immediately know the relationships, independent of their use-cases. The > > later discussion of use cases can then become clearer. > > > > We added separate sections for each use case to section 4.1 to better > describe the relationships. > > > (7) Also, the document sometimes refers to "user", and sometimes to > "user > > id" in the same context. (e.g. Section 4.1, "the user requests > > > > content".) Later, the document clarifies that the user may have > > multiple user ID's. This is confusing, because the document first talks > > about users requesting content, and then switches to say no, it's not a > > user, it's a user id. > > (8) Instead, all discussion of access requests in the document > should be > > done using consistent terminology, such as "access identifier", rather > > than "user". In some cases, the user will map 1:1 with an access > > identifier. In others, it will be 1:N. > > > where appropriate we used the term userID > furthermore we elaborated on CP-assigned user ID and NSP-assigned user > ID in section 4.2 > > > (9)... > > The actual mapping rules for NSPs and CPs to map user IDs > > with the IDs in other provider domains is a matter for the > > providers. A solution should provide an API between the > > providers to flexibly support various mapping methods. > > ... > > > > API's should be avoided. Instead, the Chargeable-User-Identity (RFC > > 4372) should be used to map identifiers to users. This is simpler, > > scalable, and already deployed. > > > > Agreed. We removed mention of the API from the framework in section 4.2 > > > > > (10) > > Section 4.3: > > > > ... > > Standardization of the logs or messages to share content > > usage information is important to support a single NSP > > sharing accounting information with multiple CPs or a > > single CP receiving from multiple NSPs. > > ... > > > > The logs should not be standardized. Instead, the contents on the AAA > > messages should be standardized. > > > > Agreed, we deleted any definitions of the log format from section 4.3 > and instead further clarified the contents of the messages themselves. > > > (11)... > > This framework specifies an accounting API provided by the > > NSP and accessed by the CP to allow for sharing user- > > behavior and content-reception information between the NSP > > AAA and CP AAA. This accounting API should be configurable > > to allow the CP to request only the logging information it > > actually requires. > > ... > > > > Negotiation of the contents of accounting messages is not a normal > > part of AAA. This requirement may be unnecessary, OR it may be very > > difficult to implement in existing AAA systems. > > As indicated above 4.3 was rewritten. The section now specifies > accounting issues specific to multicasting such as recording multicast > join and leave. > > > (12) > > ... > > When > > logging information is shared through the accounting API, > > it is important that the CP be able to match the user as > > described in the database operated by the NSP to the user > > as described in the database operated by the CP. > > ... > > > > This is already part of existing AAA systems. I'm not sure it's > > necessary to re-iterate this requirement here. > > > > Overall, Section 4.3 appears to re-state many common AAA requirements > > for accounting. > > > > The document also spends a lot of time talking about "needs". Is the > > document a framework, a model, or a requirements document? Or is it all > > three? The document should separate the model from the requirements > > more explicitly. The model should be discussed first, and then the > > requirements listed second. > > > > this text was deleted. > > > > > (13)... > > 4.4 Access Control and CP selection by NSP > > > > When a NSP receives an access request from a user, it is > > necessary for the NSP to determine to which CP the request > > is to be directed. It is necessary for the NSP to ensure > > that it is not spoofed by an inappropriate CP or user. > > ... > > > > Doesn't AAA already do this? What are the concrete requirements added > > by this document? Or is this document just introducing AAA concepts to > > people more familiar with multicast issues? > > > This section was revised to mention CP selection as a responsiblity of > the NSP. > > > (14) > > ... > > 4.5 API for Admission Control Information by NSP > > > > After authorizing a user request, the NSP may have further > > conditions for determining its admission control decision. > > MACCNT-REQ-draft defines requirements for providing the > > network capability to conduct admission control based on > > the network bandwidth usage status and bandwidth management > > policy. (MACCNT-REQ-draft, 4.2.2, 4.2.3 & 4.9) Such QoS > > measurement and policy mechanisms themselves are out of the > > scope of this memo. > > ... > > > > These mechanisms are defined (or are in the process of being defined) > > in normal AAA. This document could refer to AAA specifications that > > meet its needs. > > > > This section was greatly revised. Mention of an API was removed. More > detailed discussion of multicast-inferred bandwidth management was added > including traffic parameters of a multicast channel for admission > control which the NSP needs to know and the case of multicast and > unicast being provided on the same network. > > > > > (15) > > ... > > However the NSP's AAA Server should be > > provided with an Admission control API that allows for > > interfacing so that additional conditions can be added to > > the admission control decision. > > ... > > > > I have no idea what this sentence means. "allows for interfacing" is > > extremely vague. Also, AAA protocols do not provide for much in the way > > of capability negotiation. The authors should double-check the > > requirements of this document against the functionality provided by an > > existing AAA protocol such as RADIUS. The requirements MAY be more than > > existing protocols can satisfy. > > > > In general, AAA clients provide a set of information to the AAA server > > in the access request, and the AAA server makes an accept/deny decision > > based on that information. AAA servers cannot negotiate for more > > information. > > The text referred to above was deleted. Instead elaboration of > establishment of the connection conditioned on network resources and > channel requirements was added to section 4.5. > > > (16) > > This document should define what information is available to the > > participants. It should discuss what information SHOULD be made > > available by the AAA client to the AAA server, and what information MUST > > be made available. > > > > We agree that such info needs to be provided but not necessarily in this > draft as it is not a Requirements document. > > > > (17)... > > 4.6 Access Control and Distinguishing of Users by CP > > > > The user ID and authentication information are forwarded > > transparently by the NSP so that the CP can distinguish the > > user, as well as authenticate and authorize the request. > > ... > > > > Does this impose requirements on the behavior of the AAA systems? If > > so, what? > > > This does not introduce additional requirement for the AAA server. > > > > > (18)... > > 4.7 Caching of AAA results > > > > An NSP should be able to cache AAA results based upon an > > agreement between the NSP and a CP. The AAA cache would > > store information about permissions of a specific user to > > receive multicast data from specified channel(s) up to > > specified expiration date(s) and time(s). > > ... > > > > This is not a cache, and should not be referred to as a cache. > > Instead, the NSP obtains a policy from the AAA server for a particular > > session, and applies that policy to that session, for the duration of > > the session. The term "cache" should be deleted from the document > entirely.> > > Further: > > > > ... > > If such caching is implemented, > > ... > > > > The functionality described as a "cache" MUST be implemented. > > > > > > ... > > It should be possible for a CP to send unsolicited requests > > to the NSP to refresh or change the permissions for a user > > for specific channel(s). > > ... > > > > This is possible using existing AAA protocols. > > > > We changed "caching" terminology to proxy terminology throughout the > document. > > > (19) > > ... > > When a user is receiving multicast content and the > > permission is about to expire, the NSP may send a > > notification to the user client that his session is about > > to expire, and that he will need to re-connect. The user > > will have to reestablish a connection. > > ... > > > > In AAA terms, the user will have to re-authenticate, not re-connect. > > There is no AAA "connection" between the user and the NSP. > > > Agreed. We changed to "re-authenticate" > > Thank you > Hiroaki > -- ************************************ NTT Network Service Systems Lab. Hiroaki Sato TEL:0422-59-4683 (+81-422-59-4683) FAX:0422-59-5636 (+81-422-59-5636) ************************************ _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 13 14:58:35 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4574F28C237; Thu, 13 Mar 2008 14:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.359 X-Spam-Level: X-Spam-Status: No, score=-100.359 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2jp8k6fTU5g; Thu, 13 Mar 2008 14:58:34 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B9D828C158; Thu, 13 Mar 2008 14:58:34 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1C703A6CFE for ; Thu, 13 Mar 2008 14:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-8MzlEDz1dC for ; Thu, 13 Mar 2008 14:58:32 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 4AF6C3A6C8A for ; Thu, 13 Mar 2008 14:58:31 -0700 (PDT) Received: (qmail invoked by alias); 13 Mar 2008 21:56:10 -0000 Received: from unknown (EHLO [192.168.0.185]) [130.129.253.70] by mail.gmx.net (mp002) with SMTP; 13 Mar 2008 22:56:10 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+le+lqofql2wPIYTVvLc35ezagPtq7xLWpsyKe77 gxuAbYPrdKqY2g Message-ID: <47D9A2FA.5030408@gmx.net> Date: Thu, 13 Mar 2008 23:56:10 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 Subject: [Dime] [Fwd: Results from the Federated Roaming BBoF] X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org FYI -------- Original Message -------- Subject: Results from the Federated Roaming BBoF Date: Thu, 13 Mar 2008 22:31:50 +0100 From: stefan.winter@restena.lu To: ietf@ietf.org, int-area@ietf.org, ops-area@ietf.org CC: radext@ops.ietf.org, dime@ops.ietf.org Hi folks, this is a short summary of the Federated Roaming BBoF yesterday evening. My two Guinness hopefully left enough brain cells intact for this to be a complete report, but in case not: everybody who was there, please complete the pieces that I may have missed. RadSec ------ After an introductory explanation of our deployment scenario in eduroam - aggregation of independent administrative domains (universities) to a central national proxy, and further aggregation of nationals into a continental proxy - we figured that at least in this particular use case, there is a good reason for a reliable transport, but no need for "fancy" Diameter features - especially since eduroam lacks commercial interest, i.e. accounting. In the course of the discussion, it turned out that other people feel the exact contrary need: Diameter over UDP (reported by Avi Lior). Interestingly enough, there were also use cases in the Diameter area that would require proxy hierarchies. It was interesting to see that both of the protocols provoked the same concepts of aggregation hierarchies in certain use cases. There was also an agreement that apparently none of the two protocols is superior to the other in all aspects, and a deployer would need to make his choice. In the end there was a rough agreement of "let all the AAA transports have all the transport profiles they think they need", but the ultimate decision about that would need to be taken in radext on Friday. EAP error reporting ------------------- Basic problem statement: if an EAP session can not be established or is interrupted prematurely, there is no good error reporting mechanism back to the supplicant+user. Avi confirmed that this is not only a concern for eduroam, WiMAX deployments see the same need. It would be good to have a reporting mechanism in EAP preferably (for the WiFi case, having one in 802.1X would also do, but EAP would be the more general solution). Binding layer 2 authenticated entities to layer 3 addresses ----------------------------------------------------------- Lawful interception is one of the drivers for that, current approaches to it are snooping DHCP traffic (as discussed on int-area before the BBoF). Having a clean solution here would be desirable. Stig's approach from the mailing list (distributing keys to supplicant within EAP and DHCP server via some other mechanism to bind the leased IP address to the entity was mentioned. Stig wasn't at the BBoF but later came up with a pretty sonsistent idea. He is going to write an I-D about it. (Note from self, not discussed in meeting: It is unclear though how this works with IPv6. Relying on DHCPv6 would need to disable stateless auto-config, and IPv6 Privacy Extensions wouldn't work any more) EAP fragmentation ----------------- A report on EAP-TLS usage in eduroam came as a surprise to most participants: I had to report that EAP-TLS in the international roaming case does *not* work more often than it does. We have tracked down the likely causes to a) UDP fragmentation [authenticator adds lots of RADIUS attributes to the raw EAP data, and with EAP-TLS the EAP chunks are often = the link-layer MTU already, resulting RADIUS packet is then often > MTU between authenticator and AAA server] When staying local, chunk sizes of EAP can be tweaked to make stuff work, but when roaming to an unknown network with unknown infrastructure, this gets difficult and would have to be done at end-user side, i.e. it exceeds John Doe's capabilities and can not be considered a usable solution. Another possible cause is packet reordering and firewalls that then discard the incoming fragment because there's no observed previous fragment. We think that TCP as a transport (RadSec) could help mitigate that. There are no hard numbers and facts to prove that yet though. In any case, for plain RADIUS deployments, a max-desired-EAP-chunk discovery mechanism would be interesting. That should be pretty much it. May the force be with you, Stefan Winter _______________________________________________ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Mar 14 06:42:53 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F8F43A6999; Fri, 14 Mar 2008 06:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.443 X-Spam-Level: X-Spam-Status: No, score=-100.443 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yLu6LUD3eS8; Fri, 14 Mar 2008 06:42:52 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 829A128C8EC; Fri, 14 Mar 2008 06:42:52 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 919C028C92C for ; Fri, 14 Mar 2008 06:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CB0+dYBwJ29R for ; Fri, 14 Mar 2008 06:42:48 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 6E7E93A6F58 for ; Fri, 14 Mar 2008 06:42:06 -0700 (PDT) Received: (qmail invoked by alias); 14 Mar 2008 13:39:48 -0000 Received: from dhcp-1438.ietf71.ietf.org (EHLO [130.129.20.56]) [130.129.20.56] by mail.gmx.net (mp019) with SMTP; 14 Mar 2008 14:39:48 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18vYLEuUzEvfG0ocLzJpkODEA2vtV1WEb4LdalcCD r1mcKWFp6uVlod Message-ID: <47DA8026.3020308@gmx.net> Date: Fri, 14 Mar 2008 15:39:50 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: GEOPRIV , ecrit@ietf.org, dime@ietf.org, hokey@ietf.org X-Y-GMX-Trusted: 0 Subject: [Dime] Friday Chillout X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Who of you is going to be around this evening and is willing to hang around with other IETF folks? Please drop me a note. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Mar 17 16:48:40 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 757F428C26E; Mon, 17 Mar 2008 16:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.946 X-Spam-Level: X-Spam-Status: No, score=-100.946 tagged_above=-999 required=5 tests=[AWL=-0.509, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbUpZHCmbgaO; Mon, 17 Mar 2008 16:48:39 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8A273A6E6C; Mon, 17 Mar 2008 16:48:39 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0904D3A6E6C for ; Mon, 17 Mar 2008 16:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDvol0P6r0RU for ; Mon, 17 Mar 2008 16:48:37 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 2F0A43A6803 for ; Mon, 17 Mar 2008 16:48:36 -0700 (PDT) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id m2HNkJ8D001984 for ; Mon, 17 Mar 2008 18:46:19 -0500 (CDT) Received: from hal.lucentradius.com (phil.aaa.lucent.com [135.140.160.4]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id m2HNkISQ005473 for ; Mon, 17 Mar 2008 18:46:19 -0500 (CDT) Received: from [192.168.0.28] (rocinante.vitalaaa.com [192.168.0.28]) by hal.lucentradius.com (8.12.9+Sun/8.12.9) with ESMTP id m2HNkINg016057 for ; Mon, 17 Mar 2008 16:46:18 -0700 (PDT) Message-ID: <47DF02CA.5020002@alcatel-lucent.com> Date: Mon, 17 Mar 2008 16:46:18 -0700 From: Jan Nordqvist User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: dime@ietf.org References: <16659.193.201.228.27.1204272106.squirrel@khakasnet.ru> In-Reply-To: <16659.193.201.228.27.1204272106.squirrel@khakasnet.ru> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: [Dime] Suspected typo in RFC 4006. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org In RFC 4006, section 8.30, the following text appears: The G-S-U-Pool-Reference AVP (AVP Code 457) is of type Grouped. It is used in the Credit-Control-Answer message, and associates the Granted-Service-Unit AVP within which it appears with a credit pool within the session. I assume that text should actually be something more like: The G-S-U-Pool-Reference AVP (AVP Code 457) is of type Grouped. It is used in the Credit-Control-Answer message, and associates the Granted-Service-Unit AVP within the same Multiple-Services-Credit-Control AVP as it appears with a credit pool within the session. To the best of my understanding G-S-U-Pool-Reference AVPs are supposed to appear only within Multiple-Services-Credit-Control AVP paired with Granted-Service-Unit AVP's and not within the Granted-Service-Unit (although it could, using the famous *AVP rule), correct? Best regards, Jan Nordqvist _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Mar 18 05:29:05 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FBAE28C573; Tue, 18 Mar 2008 05:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.442 X-Spam-Level: X-Spam-Status: No, score=-101.442 tagged_above=-999 required=5 tests=[AWL=-1.005, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfjKQv7EySlb; Tue, 18 Mar 2008 05:29:04 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 228D528C5A1; Tue, 18 Mar 2008 05:28:55 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40FD03A6837; Tue, 18 Mar 2008 05:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cc8dCueFSGD3; Tue, 18 Mar 2008 05:28:53 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 9FA3128C59A; Tue, 18 Mar 2008 05:28:41 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id ADE5720514; Tue, 18 Mar 2008 13:26:23 +0100 (CET) X-AuditID: c1b4fb3c-ae09bbb00000193b-b4-47dfb4efdb79 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9595420508; Tue, 18 Mar 2008 13:26:23 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Mar 2008 13:26:23 +0100 Received: from [127.0.0.1] ([147.214.30.103]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Mar 2008 13:26:23 +0100 Message-ID: <47DFB4ED.3000303@ericsson.com> Date: Tue, 18 Mar 2008 13:26:21 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Magnus Westerlund References: <47C58EB8.1000203@ericsson.com> In-Reply-To: <47C58EB8.1000203@ericsson.com> X-OriginalArrivalTime: 18 Mar 2008 12:26:23.0059 (UTC) FILETIME=[470E0230:01C888F3] X-Brightmail-Tracker: AAAAAA== Cc: dime@ietf.org, tsvwg , NSIS Subject: Re: [Dime] [NSIS] WG last call on draft-ietf-tsvwg-emergency-rsvp-05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, There has now been a declaration of consensus in the NSIS WG regarding where to go with the admission priority field: 3) Keep Y.2171 admission priority and add admission priority as in tsvwg-rsvp-emergency to draft-ietf-nsis-qspec-19.txt. See thread starting at: http://www.ietf.org/mail-archive/web/nsis/current/msg08289.html To my understanding this means there is no need to make a major change to this document. However, some clarification may be warranted regarding the scope of the parameter that align with the NSIS QSpec updates. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 20 04:39:55 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B308B3A6A59; Thu, 20 Mar 2008 04:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.607 X-Spam-Level: X-Spam-Status: No, score=-99.607 tagged_above=-999 required=5 tests=[AWL=-0.775, BAYES_00=-2.599, DEAR_SOMETHING=1.605, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJWk3taFxr9R; Thu, 20 Mar 2008 04:39:54 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6248728C318; Thu, 20 Mar 2008 04:39:54 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1F9028C2CD for ; Thu, 20 Mar 2008 04:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4nsnGacSEeG for ; Thu, 20 Mar 2008 04:39:52 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 2FE3228C417 for ; Thu, 20 Mar 2008 04:38:47 -0700 (PDT) Received: (qmail invoked by alias); 20 Mar 2008 11:36:28 -0000 Received: from 84-230-110-8.elisa-mobile.fi (EHLO [84.230.110.8]) [84.230.110.8] by mail.gmx.net (mp026) with SMTP; 20 Mar 2008 12:36:28 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19MB84PSx5M451msH34cUzrPPTt6eKJdj0JHvJI2c nJOHbG8H7zCHkV Message-ID: <47E24C3E.4020606@gmx.net> Date: Thu, 20 Mar 2008 13:36:30 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Suriyanarayanan B References: In-Reply-To: X-Y-GMX-Trusted: 0 Cc: dime@ietf.org Subject: Re: [Dime] Regarding IPFilterRule and QoSFilterRule AVP Data Formats in RFC3588 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Suriya, based on the ongoing work on RFC 3588bis and the Diameter QoS attributes = we are in fact cleaning up the syntax and semantics of IPFilterRule and = QoSFilterRule. Have you had a chance to look at these documents? Ciao Hannes Suriyanarayanan B wrote: > > Dear Sir/Madam, > > I have an issue to be discussed on *Request for Comments(RFC): 3588.* > > In RFC 3588, Section 4.3. ( Derived AVP Data Formats), IPFilterRule = > and QoSFilterRule are Specifed as the *derived data formats from the = > OctetString AVP Base format*. > Based on the definition given, shall we consider the above two data = > formats to be taken in ABNF format. If so what is the ABNF grammar for = > that. > > So Please confirm me the same as soon as possible. > > Thanks & Regards > Suriya Narayanan B > * Software Engineer* > * A R I C E N T* > Plot No.5, Espee IT Park, 3^rd Floor, > Jawaharlal Nehru Salai, Ekkattuthangal, > Guindy, Chennai =96 600097 > Main: +91 44 66216369 > > > > > *********************** Aricent- Confidential *********************** > "DISCLAIMER: This message is proprietary to Aricent and is intended solel= y for the use of = > the individual to whom it is addressed. It may contain privileged or conf= idential information and should not be = > circulated or used for any purpose other than for what it is intended. If= you have received this message in error, = > please notify the originator immediately. If you are not the intended rec= ipient, you are notified that you are strictly > prohibited from using, copying, altering, or disclosing the contents of t= his message. Aricent accepts no responsibility for = > loss or damage arising from the use of the information transmitted by thi= s email including damage from virus." > = > > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > = _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Mar 24 23:49:06 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CDA328C232; Mon, 24 Mar 2008 23:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.764 X-Spam-Level: X-Spam-Status: No, score=-99.764 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nf5DQKkLGBd; Mon, 24 Mar 2008 23:49:04 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3693C3A6B54; Mon, 24 Mar 2008 23:49:04 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 805913A6B11 for ; Mon, 24 Mar 2008 23:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZWfWGbbs+fz for ; Mon, 24 Mar 2008 23:49:01 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [61.246.186.17]) by core3.amsl.com (Postfix) with ESMTP id B9AA73A6B44 for ; Mon, 24 Mar 2008 23:49:00 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id m2P6Wjvl012806 for ; Tue, 25 Mar 2008 12:02:45 +0530 Received: from sandesh.gur.aricent.com (sandesh [10.203.142.21]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id m2P6We0w012766 for ; Tue, 25 Mar 2008 12:02:40 +0530 To: dime@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Preeti Shandilya Date: Tue, 25 Mar 2008 12:16:03 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.5.5|November 30, 2005) at 25/03/2008 12:16:34 PM, Serialize complete at 25/03/2008 12:16:34 PM Subject: [Dime] Auth-Application-Id AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0541694577==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============0541694577== Content-Type: multipart/alternative; boundary="=_alternative 0025358D65257417_=" This is a multipart message in MIME format. --=_alternative 0025358D65257417_= Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: base64 SGkgIQ0KDQpJIGhhdmUgYSBjb25jZXJuIHJlZ2FyZGluZyB0aGUgdXNhZ2Ugb2YgQXV0aC1BcHBs aWNhdGlvbi1JZCBBVlAgcHJlc2VudCBpbiANCnRoZSBkaWFtZXRlciBtZXNzYWdlLiBJdCdzIHVz YWdlIHNlZW1zIHRvIGJlIHZhbGlkIGluIENFUiBtZXNzYWdlIGFzIA0KZGlhbWV0ZXIgbm9kZSBu ZWVkcyB0byBhZHZlcnRpc2UgdGhlIHN1cHBvcnRlZCBhdXRob3JpemF0aW9uIGFwcGxpY2F0aW9u cyANCmluIHRoZSBjYXBhYmlsaXR5IGV4Y2hhbmdlIHdpdGggdGhlIHBlZXIgbm9kZQ0KDQpCdXQg aW4gb3RoZXIgZGlhbWV0ZXIgbWVzc2FnZXMgKG90aGVyIHRoYW4gQ0VSL0NFZGltZUBpZXRmLm9y Z0EpLCAgaG93IA0KdGhpcyBBVlAgc2hhbGwgYmUgZGlmZmVyZW50IGZyb20gdGhlIGFwcGxpY2F0 aW9uIElkIHByZXNlbnQgaW4gdGhlIA0KZGlhbWV0ZXIgaGVhZGVyLiBJbiBjYXNlIG9mIE5BU1JF USBhcHBsaWNhdGlvbiwgdGhlcmUgaXMgYW4gYXV0aG9yaXphdGlvbiANCnBvcnRpb24gYW5kIGFu IGFjY291bnRpbmcgcG9ydGlvbi4gQnV0IHRoZSBhcHBsaWNhdGlvbiBvYnZpb3VzbHkgaGFzIGEg DQpzaW5nbGUgYXBwbGljYXRpb24gSWQuIFNvIGl0IGNhbiBub3Qgc2VwYXJhdGVseSBpbmZvcm0g cGVlciBub2RlIHRoYXQgbm9kZSANCmlzIHN1cHBvcnRpbmcgb25seSBhdXRob3JpemF0aW9uIHBv cnRpb24gb2YgdGhlIGFwcGxpY2F0aW9uLg0KDQpJbiBteSBvcGluaW9uLCBSRkMgMzU4OCBzaG91 bGQgbm90IG1lbnRpb24gdGhhdCB0aGUgdmFsdWUgb2YgdGhpcyBBVlAgTVVTVCANCm1hdGNoIHdp dGggdGhlIGFwcGxpY2F0aW9uIElkIG1lbnRpb25lZCBpbiB0aGUgZGlhbWV0ZXIgaGVhZGVyLiBT aW5jZSANCnRoZXJlIGFyZSBhcHBsaWNhdGlvbnMsIHNwZWNpZmljYXRpb24gY29ycmVzcG9uZGlu ZyB0byB3aGljaCBtZW50aW9uIHRoYXQgDQp0aGUgdmFsdWUgb2YgdGhpcyBBVlAgc2hhbGwgYmUg c29tZSBvdGhlciB2YWx1ZSB0aGFuIHRoZSBhcHBsaWNhdGlvbiBJZCBpbiANCnRoZSBkaWFtZXRl ciBoZWFkZXIuIA0KDQpJIHRoaW5rIHRoaXMgaXNzdWUgd2FzIHJhaXNlZCBpbiBkaWFtZXRlciBp bnRlcm9wIGV2ZW50LiBIYXMgdGhhdCBiZWVuIA0KcmVzb2x2ZWQgPyBJZiB5ZXMsIHdoZXJlIGNh biBJIGZpbmQgdGhlIGNvbmNsdXNpb24NCg0KDQpyZWdhcmRzDQpQcmVldGkNCg0KDQoqKioqKioq KioqKioqKioqKioqKioqKiAgQXJpY2VudC1VbmNsYXNzaWZpZWQgICAqKioqKioqKioqKioqKioq KioqKioqKg0KIkRJU0NMQUlNRVI6IFRoaXMgbWVzc2FnZSBpcyBwcm9wcmlldGFyeSB0byBBcmlj ZW50ICBhbmQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIAp0aGUgaW5kaXZpZHVh bCB0byB3aG9tIGl0IGlzIGFkZHJlc3NlZC4gSXQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBvciBj b25maWRlbnRpYWwgaW5mb3JtYXRpb24gYW5kIHNob3VsZCBub3QgYmUgCmNpcmN1bGF0ZWQgb3Ig dXNlZCBmb3IgYW55IHB1cnBvc2Ugb3RoZXIgdGhhbiBmb3Igd2hhdCBpdCBpcyBpbnRlbmRlZC4g SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCAKcGxlYXNlIG5vdGlm eSB0aGUgb3JpZ2luYXRvciBpbW1lZGlhdGVseS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk IHJlY2lwaWVudCwgeW91IGFyZSBub3RpZmllZCB0aGF0IHlvdSBhcmUgc3RyaWN0bHkKcHJvaGli aXRlZCBmcm9tIHVzaW5nLCBjb3B5aW5nLCBhbHRlcmluZywgb3IgZGlzY2xvc2luZyB0aGUgY29u dGVudHMgb2YgdGhpcyBtZXNzYWdlLiBBcmljZW50IGFjY2VwdHMgbm8gcmVzcG9uc2liaWxpdHkg Zm9yIApsb3NzIG9yIGRhbWFnZSBhcmlzaW5nIGZyb20gdGhlIHVzZSBvZiB0aGUgaW5mb3JtYXRp b24gdHJhbnNtaXR0ZWQgYnkgdGhpcyBlbWFpbCBpbmNsdWRpbmcgZGFtYWdlIGZyb20gdmlydXMu Igo= --=_alternative 0025358D65257417_= Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpICE8L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgaGF2ZSBhIGNvbmNlcm4gcmVnYXJk aW5nIHRoZSB1c2FnZQ0Kb2YgQXV0aC1BcHBsaWNhdGlvbi1JZCBBVlAgcHJlc2VudCBpbiB0aGUg ZGlhbWV0ZXIgbWVzc2FnZS4gSXQncyB1c2FnZQ0Kc2VlbXMgdG8gYmUgdmFsaWQgaW4gQ0VSIG1l c3NhZ2UgYXMgZGlhbWV0ZXIgbm9kZSBuZWVkcyB0byBhZHZlcnRpc2UgdGhlDQpzdXBwb3J0ZWQg YXV0aG9yaXphdGlvbiBhcHBsaWNhdGlvbnMgaW4gdGhlIGNhcGFiaWxpdHkgZXhjaGFuZ2Ugd2l0 aCB0aGUNCnBlZXIgbm9kZTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+QnV0IGluIG90aGVyIGRpYW1ldGVyIG1lc3NhZ2VzIChvdGhlcg0KdGhhbiBDRVIv Q0VkaW1lQGlldGYub3JnQSksICZuYnNwO2hvdyB0aGlzIEFWUCBzaGFsbCBiZSBkaWZmZXJlbnQg ZnJvbQ0KdGhlIGFwcGxpY2F0aW9uIElkIHByZXNlbnQgaW4gdGhlIGRpYW1ldGVyIGhlYWRlci4g SW4gY2FzZSBvZiBOQVNSRVEgYXBwbGljYXRpb24sDQp0aGVyZSBpcyBhbiBhdXRob3JpemF0aW9u IHBvcnRpb24gYW5kIGFuIGFjY291bnRpbmcgcG9ydGlvbi4gQnV0IHRoZSBhcHBsaWNhdGlvbg0K b2J2aW91c2x5IGhhcyBhIHNpbmdsZSBhcHBsaWNhdGlvbiBJZC4gU28gaXQgY2FuIG5vdCBzZXBh cmF0ZWx5IGluZm9ybQ0KcGVlciBub2RlIHRoYXQgbm9kZSBpcyBzdXBwb3J0aW5nIG9ubHkgYXV0 aG9yaXphdGlvbiBwb3J0aW9uIG9mIHRoZSBhcHBsaWNhdGlvbi48L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkluIG15IG9waW5pb24sIFJGQyAzNTg4IHNo b3VsZCBub3QgbWVudGlvbg0KdGhhdCB0aGUgdmFsdWUgb2YgdGhpcyBBVlAgTVVTVCBtYXRjaCB3 aXRoIHRoZSBhcHBsaWNhdGlvbiBJZCBtZW50aW9uZWQNCmluIHRoZSBkaWFtZXRlciBoZWFkZXIu IFNpbmNlIHRoZXJlIGFyZSBhcHBsaWNhdGlvbnMsIHNwZWNpZmljYXRpb24gY29ycmVzcG9uZGlu Zw0KdG8gd2hpY2ggbWVudGlvbiB0aGF0IHRoZSB2YWx1ZSBvZiB0aGlzIEFWUCBzaGFsbCBiZSBz b21lIG90aGVyIHZhbHVlIHRoYW4NCnRoZSBhcHBsaWNhdGlvbiBJZCBpbiB0aGUgZGlhbWV0ZXIg aGVhZGVyLiA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PkkgdGhpbmsgdGhpcyBpc3N1ZSB3YXMgcmFpc2VkIGluIGRpYW1ldGVyDQppbnRlcm9wIGV2ZW50 LiBIYXMgdGhhdCBiZWVuIHJlc29sdmVkID8gSWYgeWVzLCB3aGVyZSBjYW4gSSBmaW5kIHRoZSBj b25jbHVzaW9uPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5yZWdhcmRzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5QcmVldGk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4N Cjxicj4NCioqKioqKioqKioqKioqKioqKioqKioqICZuYnNwO0FyaWNlbnQtVW5jbGFzc2lmaWVk ICZuYnNwOyAqKioqKioqKioqKioqKioqKioqKioqKjwvZm9udD4NCjx0YWJsZT48dHI+PHRkIGJn Y29sb3I9I2ZmZmZmZj48Zm9udCBjb2xvcj0jMDAwMDAwPjxwcmU+IkRJU0NMQUlNRVI6IFRoaXMg bWVzc2FnZSBpcyBwcm9wcmlldGFyeSB0byBBcmljZW50ICBhbmQgaXMgaW50ZW5kZWQgc29sZWx5 IGZvciB0aGUgdXNlIG9mIAp0aGUgaW5kaXZpZHVhbCB0byB3aG9tIGl0IGlzIGFkZHJlc3NlZC4g SXQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gYW5k IHNob3VsZCBub3QgYmUgCmNpcmN1bGF0ZWQgb3IgdXNlZCBmb3IgYW55IHB1cnBvc2Ugb3RoZXIg dGhhbiBmb3Igd2hhdCBpdCBpcyBpbnRlbmRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBt ZXNzYWdlIGluIGVycm9yLCAKcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBpbW1lZGlhdGVs eS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBub3RpZmll ZCB0aGF0IHlvdSBhcmUgc3RyaWN0bHkKcHJvaGliaXRlZCBmcm9tIHVzaW5nLCBjb3B5aW5nLCBh bHRlcmluZywgb3IgZGlzY2xvc2luZyB0aGUgY29udGVudHMgb2YgdGhpcyBtZXNzYWdlLiBBcmlj ZW50IGFjY2VwdHMgbm8gcmVzcG9uc2liaWxpdHkgZm9yIApsb3NzIG9yIGRhbWFnZSBhcmlzaW5n IGZyb20gdGhlIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gdHJhbnNtaXR0ZWQgYnkgdGhpcyBlbWFp bCBpbmNsdWRpbmcgZGFtYWdlIGZyb20gdmlydXMuIgo8L3ByZT48L2ZvbnQ+PC90ZD48L3RyPjwv dGFibGU+ --=_alternative 0025358D65257417_=-- --===============0541694577== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0541694577==-- From dime-bounces@ietf.org Tue Mar 25 11:59:37 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3DD33A6E9E; Tue, 25 Mar 2008 11:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.978 X-Spam-Level: X-Spam-Status: No, score=-100.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KA9jJS2t42Qf; Tue, 25 Mar 2008 11:59:35 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 433BA3A6C48; Tue, 25 Mar 2008 11:59:35 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 217A73A6C30 for ; Tue, 25 Mar 2008 11:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLqSUZGx9bNW for ; Tue, 25 Mar 2008 11:59:33 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 8174B3A6785 for ; Tue, 25 Mar 2008 11:59:32 -0700 (PDT) Received: (qmail invoked by alias); 25 Mar 2008 18:57:12 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp004) with SMTP; 25 Mar 2008 19:57:12 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/4+BI2hxT4dKG5jD1MXepa3fbRBrTZ0wOGN2MG0d y3Fqi1yRzcNwX8 Message-ID: <47E94B0F.1030703@gmx.net> Date: Tue, 25 Mar 2008 20:57:19 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 Subject: [Dime] Meeting Minutes X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org We have uploaded the meeting minutes. You can find them here: http://www.ietf.org/proceedings/08mar/minutes/dime.txt Please let us know if you have comments. Thanks to Victor for preparing the meeting minutes. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 26 10:06:56 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE9C43A6CCC; Wed, 26 Mar 2008 10:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.487 X-Spam-Level: X-Spam-Status: No, score=-101.487 tagged_above=-999 required=5 tests=[AWL=-1.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmnRzCGNJNVh; Wed, 26 Mar 2008 10:06:49 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ED253A6DD2; Wed, 26 Mar 2008 10:06:49 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94BF63A6F5A; Wed, 26 Mar 2008 10:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ta6uIQ-dlNPV; Wed, 26 Mar 2008 10:06:44 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 034F828C24D; Wed, 26 Mar 2008 10:06:34 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 40D8622A77; Wed, 26 Mar 2008 17:32:07 +0100 (CET) X-AuditID: c1b4fb3e-ae198bb000004ec0-ae-47ea7a875eea Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 33F172110A; Wed, 26 Mar 2008 17:32:07 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Mar 2008 17:32:06 +0100 Received: from [127.0.0.1] ([147.214.30.213]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Mar 2008 17:32:06 +0100 Message-ID: <47EA7A86.8000209@ericsson.com> Date: Wed, 26 Mar 2008 17:32:06 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Magnus Westerlund References: <47C58EB8.1000203@ericsson.com> In-Reply-To: <47C58EB8.1000203@ericsson.com> X-OriginalArrivalTime: 26 Mar 2008 16:32:06.0767 (UTC) FILETIME=[EE4B4FF0:01C88F5E] X-Brightmail-Tracker: AAAAAA== Cc: dime@ietf.org, tsvwg , NSIS Subject: Re: [Dime] [NSIS] WG last call on draft-ietf-tsvwg-emergency-rsvp-05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Magnus Westerlund skrev: > This announces the second WG last call on "Resource ReSerVation Protovol > (RSVP) Extensions for Emergency Services" with the intended status of > proposed standard: > > http://tools.ietf.org/id/draft-ietf-tsvwg-emergency-rsvp-05.txt > > This is the second one due to changes and the interaction with documents > in the NSIS and DIME WG. Please provide any comments on the TSVWG > mailing list no later than 28th of March. (Yes, it is long but that is > due to the meeting and that we have several other WG last calls ongoing). > This is a reminder about the WG last call. Without some comments we can't judge consensus on publishing this document. So please provide any comments, even if just to say that it is ready to be published. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 27 15:07:37 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B83113A701C; Thu, 27 Mar 2008 15:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.664 X-Spam-Level: X-Spam-Status: No, score=-100.664 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YgBEkECo4qf; Thu, 27 Mar 2008 15:07:37 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F14F03A6E42; Thu, 27 Mar 2008 15:07:36 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C25D73A7020 for ; Thu, 27 Mar 2008 15:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXL6VFH71r5O for ; Thu, 27 Mar 2008 15:07:35 -0700 (PDT) Received: from isjsys5.int.i1.dk (port80.ds1-hk.adsl.cybercity.dk [212.242.60.147]) by core3.amsl.com (Postfix) with ESMTP id CE8CC3A7009 for ; Thu, 27 Mar 2008 15:07:34 -0700 (PDT) Received: from isjsys5.int.i1.dk (localhost.localdomain [127.0.0.1]) by isjsys5.int.i1.dk (Postfix) with ESMTP id 7480A31299F for ; Thu, 27 Mar 2008 23:05:01 +0100 (CET) Received: from isjsys (isjsys [10.0.0.2]) by isjsys5.int.i1.dk (Postfix) with ESMTP for ; Thu, 27 Mar 2008 23:05:01 +0100 (CET) From: Ivan Skytte =?iso-8859-1?q?J=F8rgensen?= To: dime@ietf.org Date: Thu, 27 Mar 2008 23:05:00 +0100 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) X-Accept-Language: da, en, de MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200803272305.00107.isj-dime@i1.dk> Subject: [Dime] DDDS (dynamic peer discoverey by NAPTR records) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org RFC3588 section 5.2 page 57 item 3 specifies to use NAPTR queries. Looking at RFC3402 page 4: "Flags Most Applications will require a way for a Rule to signal to the Application that some Rules provide particular outcomes that others do not; e.g., different output formats, extensibility mechanisms, terminal rule signaling, etc. Most Databases will define a Flags field that an Application can use to encode various values that express these signals." and page 10: "Expected Output: The Application must define what the expected output of the Terminal Rule should be." ... I cannot find that any flags have been defined for Diameter. Am I correct in the assumption that: 1: No flags are defined, and 2: All rules are terminal, and 3: The replacement field in the matching NAPTR records points to a DNS key that should contain SRV records. ? _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Mar 31 10:34:30 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8EB63A6AB7; Mon, 31 Mar 2008 10:34:30 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E27743A6823; Thu, 27 Mar 2008 18:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgybk5SGfjj2; Thu, 27 Mar 2008 18:08:50 -0700 (PDT) Received: from mail171.messagelabs.com (mail171.messagelabs.com [216.82.253.243]) by core3.amsl.com (Postfix) with ESMTP id 9CE4B3A683F; Thu, 27 Mar 2008 18:08:50 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-14.tower-171.messagelabs.com!1206666458!1871599!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 14531 invoked from network); 28 Mar 2008 01:08:45 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-14.tower-171.messagelabs.com with AES256-SHA encrypted SMTP; 28 Mar 2008 01:08:45 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.3.0/Switch-3.3.0) with ESMTP id m2S1BIZJ013164; Thu, 27 Mar 2008 21:11:18 -0400 In-Reply-To: <47EA7A86.8000209@ericsson.com> To: Magnus Westerlund MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Thu, 27 Mar 2008 21:07:28 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 7.0.2FP1 HF180|March 29, 2007) at 03/27/2008 09:10:45 PM, Serialize complete at 03/27/2008 09:10:45 PM X-Mailman-Approved-At: Mon, 31 Mar 2008 10:34:29 -0700 Cc: dime@ietf.org, nsis-bounces@ietf.org, NSIS , tsvwg Subject: Re: [Dime] [NSIS] WG last call on draft-ietf-tsvwg-emergency-rsvp-05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1468274432==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============1468274432== Content-Type: multipart/alternative; boundary="=_alternative 0005680D8525741A_=" This is a multipart message in MIME format. --=_alternative 0005680D8525741A_= Content-Type: text/plain; charset="US-ASCII" Just saying that, from my perspective, "it is ready to be published". And, yes I have read it and followed the discussions on the related DIME and NSIS documents. Janet Gunn Computer Sciences Corporation Registered Office: 2100 East Grand Avenue, El Segundo California 90245, USA Registered in USA No: C-489-59 ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- nsis-bounces@ietf.org wrote on 03/26/2008 12:32:06 PM: > Magnus Westerlund skrev: > > This announces the second WG last call on "Resource ReSerVation Protovol > > (RSVP) Extensions for Emergency Services" with the intended status of > > proposed standard: > > > > http://tools.ietf.org/id/draft-ietf-tsvwg-emergency-rsvp-05.txt > > > > This is the second one due to changes and the interaction with documents > > in the NSIS and DIME WG. Please provide any comments on the TSVWG > > mailing list no later than 28th of March. (Yes, it is long but that is > > due to the meeting and that we have several other WG last calls ongoing). > > > > This is a reminder about the WG last call. Without some comments we > can't judge consensus on publishing this document. So please provide any > comments, even if just to say that it is ready to be published. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www.ietf.org/mailman/listinfo/nsis --=_alternative 0005680D8525741A_= Content-Type: text/html; charset="US-ASCII"
Just saying that, from my perspective, "it is ready to be published".  And, yes I have read it and followed the discussions on the related DIME and NSIS documents.

Janet Gunn

Computer Sciences Corporation
Registered Office: 2100 East Grand Avenue, El Segundo California 90245, USA
Registered in USA No: C-489-59

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

nsis-bounces@ietf.org wrote on 03/26/2008 12:32:06 PM:

> Magnus Westerlund skrev:
> > This announces the second WG last call on "Resource ReSerVation Protovol
> > (RSVP) Extensions for Emergency Services" with the intended status of
> > proposed standard:
> >
> > http://tools.ietf.org/id/draft-ietf-tsvwg-emergency-rsvp-05.txt
> >
> > This is the second one due to changes and the interaction with documents
> > in the NSIS and DIME WG. Please provide any comments on the TSVWG
> > mailing list no later than 28th of March. (Yes, it is long but that is
> > due to the meeting and that we have several other WG last calls ongoing).
> >
>
> This is a reminder about the WG last call. Without some comments we
> can't judge consensus on publishing this document. So please provide any
> comments, even if just to say that it is ready to be published.
>
> Cheers
>
> Magnus Westerlund
>
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www.ietf.org/mailman/listinfo/nsis
 --=_alternative 0005680D8525741A_=-- --===============1468274432== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1468274432==-- From dime-bounces@ietf.org Mon Mar 31 10:34:31 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E4A93A6E45; Mon, 31 Mar 2008 10:34:31 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 300ED28C3F7 for ; Mon, 31 Mar 2008 03:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.129 X-Spam-Level: X-Spam-Status: No, score=-1.129 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7tlJY1erpGs for ; Mon, 31 Mar 2008 03:01:25 -0700 (PDT) Received: from mx1.cboss.ru (mx1.cboss.ru [195.245.232.31]) by core3.amsl.com (Postfix) with ESMTP id 6551228C440 for ; Mon, 31 Mar 2008 03:00:59 -0700 (PDT) Received: from z102737.int.cboss.ru (z102737.int.cboss.ru [10.1.200.15]) by mx1.cboss.ru (8.13.1/8.13.1) with ESMTP id m2VA0sVd027547 for ; Mon, 31 Mar 2008 14:00:54 +0400 Received: from MAILSRV3.int.cboss.ru (unverified) by z102737.int.cboss.ru (Content Technologies SMTPRS 4.3.12) with ESMTP id ; Mon, 31 Mar 2008 14:00:54 +0400 Received: from l102796.int.cboss.ru ([10.2.131.5]) by MAILSRV3.int.cboss.ru with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Mar 2008 14:00:54 +0400 Message-ID: <47F0B655.4080309@cbossgroup.com> Date: Mon, 31 Mar 2008 14:00:53 +0400 From: Igor Mammedov User-Agent: Thunderbird 2.0.0.12 (X11/20080213) MIME-Version: 1.0 To: dime@ietf.org X-OriginalArrivalTime: 31 Mar 2008 10:00:54.0757 (UTC) FILETIME=[1BF39150:01C89316] X-Mailman-Approved-At: Mon, 31 Mar 2008 10:34:29 -0700 Cc: rigir2000@mail.ru, preeti.shandilya@aricent.com Subject: Re: [Dime] Transient Failures in DCCA X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org >> Please, give the comments upon RFC 4006 on next conclusion: >> When server in CCA Update return Result_Code = 4010 or 4011 or 4012. >> Server MUST or not MUST wait from client CCR Terminate? > Server should not wait to get terminate request from client after sending CCA with result code 4010 or 4011 or 4012. The reason is that client shall clear the session contexts > on receiving any of these result codes from server and then it shall never send terminate request Then we possibly have a typo in rfc4006. It says that client MUST send stop CCR. Page 16, " 5.1. General Principles ... If service specific re-authorization fails, the user will be disconnected, and the credit-control client MUST send a final interrogation to the credit-control server. " But: account being empty = 4012 (transient failure) Page 47, " The event 'Not successfully processed' means that the credit-control server could not process the message; e.g., due to an unknown end user, account being empty, or errors defined in [DIAMBASE]. " and server's state machine says that session is gone after such error: Page 55, " Open CC update request Send Idle received but not CC update successfully processed answer with Result-Code != SUCCESS, debit used units " Client's state machine does not mention the event 'Not successfully processed' at all. So it looks like rfc conflicts within itself and do not completely describe behavior in case of "Transient Failures". PS: Is it reasonable to kill session, lets say on error 4012, and possibly loose the last granted units because server is not going wait for service termination and 'final interrogation'. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Mar 31 10:34:31 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 465A93A6E68; Mon, 31 Mar 2008 10:34:31 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FB303A6814; Mon, 31 Mar 2008 07:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsyqOu1XQxIK; Mon, 31 Mar 2008 07:37:43 -0700 (PDT) Received: from mxoutps1.us.army.mil (mxoutps1.us.army.mil [143.69.250.38]) by core3.amsl.com (Postfix) with ESMTP id 8ED503A6E84; Mon, 31 Mar 2008 07:37:41 -0700 (PDT) DomainKey-Signature: s=ako; d=us.army.mil; c=nofws; q=dns; h=From:X-AKO:X-IronPort-AV:Received:Received:To:Cc: Message-ID:Date:X-Mailer:MIME-Version:Content-Language: Subject:X-Accept-Language:Priority:In-Reply-To:References: Content-Type:Content-Disposition: Content-Transfer-Encoding; b=At8qcinbpUzj8nrcxM9rTbcgkjg9AEhl9L1b/lJ2lIau/zVERQ2pqyvJ bsNoxF37j8HB0NSnjzzd/RKXUw43Yg==; From: "Roy, Radhika R Dr CTR USA USAMC" X-AKO: 116504073:10.224.36.65:31 Mar 2008 14:37:38 +0000:$Webmail:None X-IronPort-AV: E=Sophos;i="4.25,583,1199664000"; d="scan'208";a="116504073" Received: from mail5.int.ps1.us.army.mil (HELO us.army.mil) ([10.224.36.65]) by mxoutps1.us.army.mil with ESMTP; 31 Mar 2008 14:37:38 +0000 Received: from [10.240.32.176] (Forwarded-For: 134.80.13.193, [10.240.32.176]) by mail5.int.ps1.us.army.mil (mshttpd); Mon, 31 Mar 2008 10:37:38 -0400 To: Magnus Westerlund ,Janet P Gunn Message-ID: Date: Mon, 31 Mar 2008 10:37:38 -0400 X-Mailer: Sun Java(tm) System Messenger Express 6.2-9.04 (built Jun 11 2007) MIME-Version: 1.0 Content-Language: en X-Accept-Language: en Priority: normal In-Reply-To: References: <47EA7A86.8000209@ericsson.com> Content-Disposition: inline X-Mailman-Approved-At: Mon, 31 Mar 2008 10:34:29 -0700 Cc: dime@ietf.org, NSIS , nsis-bounces@ietf.org, tsvwg Subject: Re: [Dime] [NSIS] WG last call on draft-ietf-tsvwg-emergency-rsvp-05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, Magnus: There is an important typo in reference to NSIS-QSPEC priority. NSIS-QSPEC is version 19 and resource-priority is in Section 5.2.9 (not Section 6.2.9). More importantly, this draft needs to reference ONLY to this of part of the resource-priority that is successfully resolved by the NSIS WG in relation to the consensus of the QSPEC draft (e.g. not to specifically mention Y.xxxx resource-priority ONLY, etc. because it will create confusions and distractions about the main technical aspects). Ken and other members need to look into this as they have taken the lead in resolving the issues related to the QSSPEC draft. Otherwise, the draft seems to be well-written, and I also agree with Janet other than the above. Sorry that I missed the last Friday's deadline. Best regards, Radhika PS: For SIP and SIPPING WG members: RFC 3312 and RFCs related to SIP call flows need to use the latest RFCs of NSIS and TSVWG for taking care of QOS. ----- Original Message ----- From: Janet P Gunn Date: Thursday, March 27, 2008 21:09 Subject: Re: [NSIS] WG last call on draft-ietf-tsvwg-emergency-rsvp-05 To: Magnus Westerlund Cc: dime@ietf.org, nsis-bounces@ietf.org, NSIS , tsvwg > Just saying that, from my perspective, "it is ready to be > published". And, > yes I have read it and followed the discussions on the related > DIME and > NSIS documents. > > Janet Gunn > > Computer Sciences Corporation > Registered Office: 2100 East Grand Avenue, El Segundo California > 90245, > USA > Registered in USA No: C-489-59 > > ------------------------------------------------------------------- > ------------------------------------------------------------------- > ------------------------------------------------------------------- > ------- > This is a PRIVATE message. If you are not the intended recipient, > please > delete without copying and kindly advise us by e-mail of the > mistake in > delivery. > NOTE: Regardless of content, this e-mail shall not operate to bind > CSC to > any order or other contract unless pursuant to explicit written > agreement > or government initiative expressly permitting the use of e-mail > for such > purpose. > ------------------------------------------------------------------- > ------------------------------------------------------------------- > ------------------------------------------------------------------- > ------- > > > nsis-bounces@ietf.org wrote on 03/26/2008 12:32:06 PM: > > > Magnus Westerlund skrev: > > > This announces the second WG last call on "Resource > ReSerVation > Protovol > > > (RSVP) Extensions for Emergency Services" with the intended > status of > > > proposed standard: > > > > > > http://tools.ietf.org/id/draft-ietf-tsvwg-emergency-rsvp-05.txt > > > > > > This is the second one due to changes and the interaction with > documents > > > in the NSIS and DIME WG. Please provide any comments on the > TSVWG > > > mailing list no later than 28th of March. (Yes, it is long but > that is > > > > due to the meeting and that we have several other WG last > calls > ongoing). > > > > > > > This is a reminder about the WG last call. Without some comments > we > > can't judge consensus on publishing this document. So please > provide any > > > comments, even if just to say that it is ready to be published. > > > > Cheers > > > > Magnus Westerlund > > > > IETF Transport Area Director & TSVWG Chair > > ----------------------------------------------------------------- > ----- > > Multimedia Technologies, Ericsson Research EAB/TVM > > ----------------------------------------------------------------- > ----- > > Ericsson AB | Phone +46 8 4048287 > > Torshamsgatan 23 | Fax +46 8 7575550 > > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > ----------------------------------------------------------------- > ----- > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www.ietf.org/mailman/listinfo/nsis > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Apr 1 04:48:31 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 616943A6BE6; Tue, 1 Apr 2008 04:48:31 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A073B28C1E0; Tue, 1 Apr 2008 04:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dwl7ygfblc07; Tue, 1 Apr 2008 04:48:28 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9357D3A6B26; Tue, 1 Apr 2008 04:48:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,587,1199660400"; d="scan'208";a="5031981" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 01 Apr 2008 13:48:24 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m31BmODB002818; Tue, 1 Apr 2008 13:48:24 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m31BmOPq022635; Tue, 1 Apr 2008 11:48:24 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Apr 2008 13:48:24 +0200 Received: from [144.254.53.198] ([144.254.53.198]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Apr 2008 13:48:24 +0200 In-Reply-To: References: <47EA7A86.8000209@ericsson.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <0E405955-620F-43D9-8EB4-F070F8948A1C@cisco.com> From: Francois Le Faucheur IMAP Date: Tue, 1 Apr 2008 13:48:17 +0200 To: "Roy, Radhika R Dr CTR USA USAMC" X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 01 Apr 2008 11:48:24.0161 (UTC) FILETIME=[4A824510:01C893EE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4784; t=1207050504; x=1207914504; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20[Dime]=20[NSIS]=20WG=20last=20call=20on =20draft-ietf-tsvwg-emergency-rsvp-05 |Sender:=20; bh=I2XvpoGo/+ZSJYwy+ji6eBE05Fkb/UJYYivwsxry1Yc=; b=Frub0AHp8NPGDn6NuLwQUCt1T4cDlWIdReoOfthEND6/fadQbj6fbnR2FW NaTXUqcUGKhF5krBl2NEbzAfw44CsIDlBntcPVT3sN2FBF9uqfB/9jq+fQqf zhv6CcPTYb; Authentication-Results: ams-dkim-2; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: tsvwg , NSIS , nsis-bounces@ietf.org, dime@ietf.org, Janet P Gunn Subject: Re: [Dime] [NSIS] WG last call on draft-ietf-tsvwg-emergency-rsvp-05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Roy, On 31 Mar 2008, at 16:37, Roy, Radhika R Dr CTR USA USAMC wrote: > Hi, Magnus: > > There is an important typo in reference to NSIS-QSPEC priority. > NSIS-QSPEC is version 19 and resource-priority is in Section 5.2.9 > (not Section 6.2.9). Because I feared a change of section numbering in the next version of nsis-qspec I removed the section number (just referred to the section title). So this is solve in -06. > > More importantly, this draft needs to reference ONLY to this of > part of the resource-priority that is successfully resolved by the > NSIS WG in relation to the consensus of the QSPEC draft (e.g. not > to specifically mention Y.xxxx resource-priority ONLY, etc. because > it will create confusions and distractions about the main technical > aspects). Right. -06 only refers to the nsis-qspec "Admission Priority" and not to the nsis-qspec "Y.xxx Admission Priority". Thanks for your review. Francois > > Ken and other members need to look into this as they have taken the > lead in resolving the issues related to the QSSPEC draft. > > Otherwise, the draft seems to be well-written, and I also agree > with Janet other than the above. > > Sorry that I missed the last Friday's deadline. > > Best regards, > Radhika > > PS: For SIP and SIPPING WG members: > > RFC 3312 and RFCs related to SIP call flows need to use the latest > RFCs of NSIS and TSVWG for taking care of QOS. > > > ----- Original Message ----- > From: Janet P Gunn > Date: Thursday, March 27, 2008 21:09 > Subject: Re: [NSIS] WG last call on draft-ietf-tsvwg-emergency-rsvp-05 > To: Magnus Westerlund > Cc: dime@ietf.org, nsis-bounces@ietf.org, NSIS , tsvwg > >> Just saying that, from my perspective, "it is ready to be >> published". And, >> yes I have read it and followed the discussions on the related >> DIME and >> NSIS documents. >> >> Janet Gunn >> >> Computer Sciences Corporation >> Registered Office: 2100 East Grand Avenue, El Segundo California >> 90245, >> USA >> Registered in USA No: C-489-59 >> >> ------------------------------------------------------------------- >> ------------------------------------------------------------------- >> ------------------------------------------------------------------- >> ------- >> This is a PRIVATE message. If you are not the intended recipient, >> please >> delete without copying and kindly advise us by e-mail of the >> mistake in >> delivery. >> NOTE: Regardless of content, this e-mail shall not operate to bind >> CSC to >> any order or other contract unless pursuant to explicit written >> agreement >> or government initiative expressly permitting the use of e-mail >> for such >> purpose. >> ------------------------------------------------------------------- >> ------------------------------------------------------------------- >> ------------------------------------------------------------------- >> ------- >> >> >> nsis-bounces@ietf.org wrote on 03/26/2008 12:32:06 PM: >> >>> Magnus Westerlund skrev: >>>> This announces the second WG last call on "Resource >> ReSerVation >> Protovol >>>> (RSVP) Extensions for Emergency Services" with the intended >> status of >>>> proposed standard: >>>> >>>> http://tools.ietf.org/id/draft-ietf-tsvwg-emergency-rsvp-05.txt >>>> >>>> This is the second one due to changes and the interaction with >> documents >>>> in the NSIS and DIME WG. Please provide any comments on the >> TSVWG >>>> mailing list no later than 28th of March. (Yes, it is long but >> that is >> >>>> due to the meeting and that we have several other WG last >> calls >> ongoing). >>>> >>> >>> This is a reminder about the WG last call. Without some comments >> we >>> can't judge consensus on publishing this document. So please >> provide any >> >>> comments, even if just to say that it is ready to be published. >>> >>> Cheers >>> >>> Magnus Westerlund >>> >>> IETF Transport Area Director & TSVWG Chair >>> ----------------------------------------------------------------- >> ----- >>> Multimedia Technologies, Ericsson Research EAB/TVM >>> ----------------------------------------------------------------- >> ----- >>> Ericsson AB | Phone +46 8 4048287 >>> Torshamsgatan 23 | Fax +46 8 7575550 >>> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >>> ----------------------------------------------------------------- >> ----- >>> >>> _______________________________________________ >>> nsis mailing list >>> nsis@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsis >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Apr 1 05:31:14 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E141295202; Tue, 1 Apr 2008 05:31:00 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A34D294D00; Tue, 1 Apr 2008 05:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.603 X-Spam-Level: X-Spam-Status: No, score=-5.603 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, HELO_EQ_SE=0.35, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGoU6PysBqq7; Tue, 1 Apr 2008 05:28:46 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id AE9CC28D36D; Tue, 1 Apr 2008 05:17:21 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 20FA6217E5; Tue, 1 Apr 2008 14:14:50 +0200 (CEST) X-AuditID: c1b4fb3e-af99bbb000004ec0-29-47f2273afaea Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1073A2178E; Tue, 1 Apr 2008 14:14:50 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Apr 2008 14:14:49 +0200 Received: from [127.0.0.1] ([147.214.30.213]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Apr 2008 14:14:49 +0200 Message-ID: <47F22739.90701@ericsson.com> Date: Tue, 01 Apr 2008 14:14:49 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 References: <20080331194501.4519028C3B8@core3.amsl.com> In-Reply-To: <20080331194501.4519028C3B8@core3.amsl.com> X-Enigmail-Version: 0.95.6 X-OriginalArrivalTime: 01 Apr 2008 12:14:49.0514 (UTC) FILETIME=[FB73F0A0:01C893F1] X-Brightmail-Tracker: AAAAAA== Cc: dime@ietf.org, tsvwg@ietf.org, NSIS Subject: [Dime] Confirmation on draft-ietf-tsvwg-emergency-rsvp-06.txt ready for publication X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, This is a call for confirmation that the changes since the previous version is okay and that we can forward and request publication of this document. So any final comment should be be sent to the TSVWG list no later than the 7th of April. The diff: http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-emergency-rsvp/draft-ietf-tsvwg-emergency-rsvp-06-from-05.diff.html Cheers Magnus Internet-Drafts@ietf.org skrev: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Area Working Group Working Group of the IETF. > > > Title : Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services > Author(s) : F. Le Faucheur, et al. > Filename : draft-ietf-tsvwg-emergency-rsvp-06.txt > Pages : 32 > Date : 2008-03-31 > > An Emergency Telecommunications Service (ETS) requires the ability to > provide an elevated probability of session establishment to an > authorized user in times of network congestion (typically, during a > crisis). When supported over the Internet Protocol suite, this may > be facilitated through a network layer admission control solution, > which supports prioritized access to resources (e.g., bandwidth). > These resources may be explicitly set aside for emergency services, > or they may be shared with other sessions. > > This document specifies RSVP extensions that can be used to support > such an admission priority capability at the network layer. Note > that these extensions represent one possible solution component in > satisfying ETS requirements. Other solution components, or other > solutions, are outside the scope of this document. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-06.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > -- Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime