;)

From akstcfarmingdalemnsdgs@farmingdale.edu Sun Nov 05 10:00:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgjTi-0000uh-Aq; Sun, 05 Nov 2006 10:00:06 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgjTi-0002Bo-6l; Sun, 05 Nov 2006 10:00:06 -0500 Received: from cdma-57-167.msk.skylink.ru ([83.217.57.167] helo=paritet-k9) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GgjSa-0007rL-9w; Sun, 05 Nov 2006 10:00:06 -0500 Received: from 137.125.248.33 (HELO snyfarvp.farmingdale.edu) by lists.ietf.org with esmtp (Y60WH2P-0S-2 OT'3) id .*03-8-L1>3SF-)Y for ion-archive@lists.ietf.org; Sun, 5 Nov 2006 15:08:33 -0180 Date: Sun, 5 Nov 2006 15:08:33 -0180 From: "Nicholas Kendall" X-Mailer: The Bat! (v2.10.01) Business X-Priority: 3 (Normal) Message-ID: <791126219.78907732320242@thebat.net> To: ion-archive@lists.ietf.org Subject: Feel young MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------8FB252CD39B2CD31" X-Spam: Not detected X-Spam-Score: 2.6 (++) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 ------------8FB252CD39B2CD31 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable ;)

children silly. if i wished to think sl= ightingly of anybody's children, it should not be of my own,
"since writ= ing the above, dearest lizzy, something has occurred of a most unexpected a= nd
"my object then," replied darcy, "was to show you, by every civility = in my power, that i was not
a merely conditional recommendation, and to = assert that i had forfeited all claim to it by extravagance,
de bourgh."= it vexed her to see him expose himself to such a man. mr. darcy was eyeing= him with
elizabeth herself, this invitation was so far from exciting in= her the same feelings as in her mother and
addressed him a second time = with:-"it is your turn to say something now, mr. darcy. i talked about
= distinguished her by any particular attention; and, consequently, after a = moderate period of
drawing-room were larger; but ashworth is too far off= ! i could not bear to have her ten miles from me;
"does that young lady = know mr. darcy?"
destitute enough. things are settled so oddly."
asse= mbled, had lost much of its animation, and almost all its sense by the abse= nce of jane and
"can such abominable pride as his have ever done him goo= d?"
assure you. it is a pity they are not handsome! not that i think cha= rlotte so very plain-but then she is
be angry."
derbyshire, and ther= efore felt for the awkwardness which must attend her sister, in seeing him = almost
"i have found out," said he, "by a singular accident, that there = is now in the room a near relation
couples."

------------8FB252CD39B2CD31 Content-Type: image/gif; name="ttxmc.gif" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhaQH7AaIAAP////8AAMyZAJkAAACZAAAA/wAAAAAAACH5BAAAAAAALAAAAABpAfsBAAP+ CLrc/jDKSau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqPyKRyyWw6n9CodEqt Wq/YrHbL7Xq/4LB4TC6bz+i0es1uu9/wuHxOr9vv+Lx+z+/7/4CBgoOEhYaHiImKizIBARCOkI9h kSWVDpcNmRsEBBCdn55VoA+kDqY0k5WqCqutrayOspMtmyGymLQZm6qsAL2vv7DBF6KkxgrHycnI nc6oAM/ODdLP0dWiDNjZ0KbGyNHMy+HX4zOPkbro6Azrwgu2K/EfuJq6GLbu6r/s8PzvGTyByhZu oLZy37QRRMWQoEIK3RIu6IbwoMGJFW3MypX+rx68eyzmdUh3T+SEeBvtdTQ5wRq1aS+9OZT5cqJD mxBvDuR28xo0nzphavT4cWVJWiQvZVKaEla9WUw9Jo1A0l67plOhqiPqFGRTDS4V/gwbEedDcaV6 1qx5TG1Ym2OFpvq3L107uleLfhy29x/fpXz7+tUqSbDfw6ugBvZnl3G/V40DZlx2kbJAtGbLndV8 Su1mnDs/TS54GWPlRn+DuXq3GvHRw3Rfo9xqlaXrvLBj59KUmrUvYAAtSASnjJyyspgxbxOIrbPz twc1EyeO1rOLedi9In09GPjer7B5uTu5Hbf43OgX497t4Wfyzw3hL3Rr/X1bzmlD6a/C1Gr+966K 8SMVbXmxpNWAAG7U0RXNiQWde/iFUo1ZELbRn3nAGfgUgd+B5J9giRX2IRXxZYYfhBWauFaEb1wI IoIUhGiYblR5KGN27I0yE08rokjfe/LN4WJgXy312H/rySiif0NWNeIUcQF5X35UVoicG4SdN6OA AxKF1ZcSzLYYYemB94R7oT23DYvVeRYlI3DGKeecdNZp55145qnnnnz26eefgAYq6KCEFmrooYgm quiijDbq6KOQRirppJRWaumlmGaq6aacdurpp6CGKuqopJZq6qkVGKCqqgusuioDBsDq6gOxwgqA q7U6MKsCrLbaAK6s5srrrbjquiuwsQr+eyuxtvY67KvOLsvrq78Km2yx1tpKLLXVcrutsrsy66sg 2UpLq7bD/qpuuehKG62y46brK7ztmmsvuOI+W26t78prb77LwstuwOrWyy+6+w78x74QJBuvv/86 /PC/BOdK773rSnCxv/hKXPG4B1tMccbP6jrvyRqfS3Kz5m6sB8PnimzwyhGb7PHFCnuscsMz30xw uiGjHIHPAgut8871/syyzIEUO+2xIBc88bXeQvzzwUgj+220T3Ods7slgy120CmDDSzQYm9NK9Q0 h4110xzv/DbEHZfNctgmTz3y0O3WXbLIWAPestcn00s0zykXrbjQgDBtONt634245Ef+P+y3BQNf 7rDgaW8utbye28x40m0rbfTee8DcM+kyu4zxvTivznffUs8drKxot2r757eL7vbnNb/+urWu49Ex tuuGayzTQ3NL/OQ1n90t4d1arnOwvU+re9XPSx981497q/y31qNq/vnop6/++uy37/778Mcv//z0 12///fjnr//+/Pfv//8ADKAAB0jAAhrwgAhMoALvdzZsOa1r+aIatR4Ivu05y4HiAxe/jgW48Tlv g7gDGge1J6sLTrB4l+IawEhYraeBzmIwDGGvZghC3a0Nhtey4QTF9S4TsnBb+tJhDUmIvRaKSoVI fBwEY8jCHhKxhk5cngQjOMUcPpH+il6DFhV5+DxmZXFUSfzg2vTlwyZ2kYZPhJbyqmhFL5KvjEWE YLPUaEPyyVCCQwQVDdtYRyNukIlbtCAOy/hDkIHQh38MZBwL6a5F7lGD2kOjCjuFSIEpcXB9JKQX Y6jJSVpyi5wM5QORKMQ6evCQqARjKI01RuERMopo5GIIgbdJHc7ximbMWxBz6UcrTlKPGNTkEhFG PO6tMpKz8iQr1YaxUQKSlIbM4A0HycgFWvOa2MymNrfJzW5685vgDKc4x0nOcprznOhMpzrXyc52 uvOd8IynPOdJz3ra8574zKc+98nPfvrznwANKB/G14ILRqEACEXoAhKqUIYWwAH+Dl0oQwEQ0YhK FKIKVYBFKTpRjia0AR/VqEVH2lGPPpSkITUDClNgUChk9KUPvShHQRpTmDIgoyJ9AE4lGtOZzhSn Da1pTz1KU5n+VKgy3elOzxA+Fz5ye3JknsQSCUQTMs8GNvVpTre61axyVas3HepRu3rSngaVq2c1 KlDLilakGhUNRfud0jTXsrv5jWxpu0FWK2rWoe51onxNKVjHalK3EnatYEVsTr0K049utAxxvRre /ugz05ltmGYjqF5LqtS+hjWlnQ2rTsWaVpsi9rFpbetFUWtYkQp2DJGd6mTr2rrghU6yluVBakP7 1d369bej/SxgkXpatrqWs57+XaxxyQqBpcK2dmOj7emsxkmU4XVuWHUrb5f6V9G+9a3FVe5qtZtc rYbXvK31LlNPGDgyUtNxunxqe4FoNRoU17ElVWtZ8Yvf0fZXuaDt6HnRK1zDBvXACBar8TSwUoH+ oMETc7CEJ0zhClv4whjOsIY3zOEOe/jDIA6xiC8AYR24rsTmIyiKa1DM2dWXwVWzG/QqIA24yGQa NW7UVY+QzAgH0gMrPnFAhkPkz+i4cI2kKupcUFmKXQ8E+CIjF62au5y06coqYlQH8VbXJRe0y7Yl HYzfJtu5StfLFCoyUJgjF0VB7nqapcEO6RauFc+uzNc9czHIwmcjaxm6Ctv+wW1j5+MOkK29nMtt S5gDGh5leVFRNl1tcTBouomZA/C97GyxG4EpeXo+kYo0VZ13gzq3NF4xzsAaoxawD87XyuKgSY1T hE07s3TEJO6BrXHN614zYdfX6TAFaamxOGMOH1exjQiMveMPDGAACng2AJ5N7WlTG9rRxra0F7Bt aV8b2t/mtraxLe5qfxvc12ZAuK3N7Wynu9zdJre3x10EFKIY2Gjuyl88ZIJm55sD8Wa3uLNNcIEX fN7qprfAt13wBjA84Aaft7YN7oCAPxzdDReCyzhI5vjOMMmj/vgD7MKdFThuj622KqchYHFyL1ze 1U44wRn+cng73OUDP7j+wtmdboyznN4XdzfOg6Bive1YcR1P9N4isyUUHF3PlW3wu8MNcWvTXOhC 9/nFr77uhkM86OhG+M9jHnSrD50IVOsy1AxnQTDj8d9F4vcJ1qjFTRdaAlN3edczbnOK753i8IZ5 4HPOc3e/XO9AFzzfjSBqtY8s6aj+XoyQxGTQnS7RKM67zLl+ds0PnPN4VzzPRe/tz4u+5mUHvMYj Z+YXQ97ySr8YO5z0gkmbGfMv/jnha757mWe86qr3fcQVDnZ1D9/3Yj8+jz3JXn+/t4RKFvnIN2Sm uWtrhFGfswW2nvzU33zwqb+62RFP+HiT3fjjR3zMxy/8LeA79xaQ+xL+3s/AD6R6F1G4v6/3z//+ +///ABiAAjiABFiABniACJiACriADNiADviAEBiBEjiBFFiBFghi4ncBGUgCG/gAHbgDG/iBHiCC I0CCFGCCStB1Kthz77Z4Gnh2HOhzofd9PBCCMLgB3qcCJPiBKNh+P/B1xEd+FXeDJ0iEIdCDPVgD NliCp6eDRhh8vVcBSTgDQKhzPph1fWd2Cbd+LZh362dzCEd15tdyXNiCqGeGWMd+WLiFYzhzGPd3 LFiGnGdu3DdzvOeFOCeGOjeH4zaFTmiFhydxNAd8o+eBieeGiOh35Cd2LYeIjaiIibiEjziIh1iI YbhzyseIQkiIglj+iGc4hJGodULIeziwgmV4hXcYh3mYeKqoie13iVbYiJO4iaJ4c3QYishXi7AI fGUniJQIiHqYhumnerM4jOWHiTbQfTL4i6DoiW2Yc8nHd7y4iLXojG9YiczoitCoi5hYjOemjV5X ic3ojTCXg+JHjroHiKUYhOoYfMW4e4/Ye9O4edXoivbYjdhIi58IidYIjPi4jVBYhfEIjouHjoYI kDkAdoIXjDQ4hmG3inLokKSIdbB4hmRXj2gohl+IhUC4kevWhewIeLcYiPpIkpnYh+ZnixKphuUm jJwign54gVo4ATEpkyNWkzCAkxmgkxjQgTwpKj+pATDZhCmwg0/+WITCB3o+EJR9wJQlkINF+YQ/ yYxQmCd4qJJh13cfiYytqJUgeZF1aHoeSYcRiZVW55XTlorP6JURqX4PGYR8mIYauYYzuZXCiIZL kI0lCXrv+HtcyY24mIEE2YvV6I/fx4KpWJX9OI+xKIOvmI+4SI+OKI5Q4Hl6uYfamJF7iZiLqZGr OJGEaYyGyX5hOYyCyZmDqXiXqJSN2ZomKYueKQWouZn7uJZ+GZiQeY5fmJoAuYS1uYyneIUGSZWz SJW/iZvIqZtOuY6gyY59qZu5eJzxSIORGY6JOI65uZB/iZ3HeYzXyY+uOZyA6ZtO8JWfqZbgeJqZ OZtrGJuSKZL+67mbIcmQHZmSbIiRYzmeG1mXF9mYbfmbZHmUbrCcMzgpBPoHB6qSlZKgNtmgf8Kg OymgQQChL3gE0YiUagChKHih20eULEChHZqTnCmFjnmQLghwEvqDKRqVI7iiJgCiJCqiHcCh1Amj RBCMvsiWEoeZZhmGdxmggUiXmrmSLMmSmqeJv4iSPPqja4mXkGiKhziNOeqSalh6z+ikNyCeh+mc Jdqa7EmcgOmJEXCPt9mZlth5I1mRfKmPPIiYnHiNzdmb/zh6FdmOCQmX88meZ2qidXpu4EmmdDp0 OFqYFnmLq3mepvmWKPmQWceoJhqZemibJyma+yimlHqnS6r+pXvKncpIncf3jmaoqa4ZeGA5imva kEqqnGj6nmQqqaHpm51qnD1Qda8KmZuKqmLKmp9qq2UKqJcJnfCZlJ+plEkKg9FYrMlJlLWajrE6 iioanOiJkUF6n5a6lSl5pawoqHq6d/WZp7o6qKXqqKTZn/CIn32KpubqljuHrfupouJEoDaKqeEE ry7qoHISryFKk/UahQU6BUi4rxGKim2Ar955ogKbrwarmGMqoX4YkzTqqf0qlHA6BwRrnQl7sfra kwC7Ag7LsAKKk7JaBKXHn/85kyZrpOQqqSSbqmlasjpajnpJiWXJkW/ZnjVLlys7hLsYhzhLkaWa hZFKqM/+OqzZ+Z0IaXrVyY+dipwBGabIyqlFi459Oanl2o9WW6YTaaYE6a7gl52qiKtVGq5u2ajK F6hbO6hxqplu+KVOO7G82Y7IKpD4SKvW2qpKOgTLaqYKKqeZeoMjarGWGqd6G7Nsep5qqp9JG5pV u55ZO6LEirgnCwR5C6jNGJ6kZ4QXGn4lypi+6qy/arhuC7lvK7iTabkHaY5Re7mSq67RSrOPK6Ss C7ReaHgrCYfbGqriCrvhOrih27M/q6CHu7ZxaXhhu7tLq7BMULFwwKDKK69YgKX32q7OJr1c0Lz2 SgX/mgTS65TWy4QVupQbKwMbqq3fG6PJiKjcG75U6KH+6YihLBeDz0u+COu+NMCa6ZuC7PuoGdu+ R6i+L9CyPku4aAmfrvq7c0mlJMuGKMuXcnm3JnuVVGqZdzuyAVyaS6qFeDmW1hiW9Qm+lUqMbRu4 7/mYkEqo0zmpUiq6RBudp8m0nViwo/udghmswQubGKuE3EiIvBu5NKuzXOqf8mm0tYq7pGq2i7qy L4yQeMihQxzE46rD23moviiu0Hu+6AnC0rmfJ+yzJdy0QqyaXQq4X8yjqhqd/AmxKGys5grCuOun unqyVVy/JtylnRu4W4y0VvuwJ5y3lXuqZmy0VVu2b5zGujePPim/b7qliqwDEvmVucjBfwmWCtzA /pj+n8h4lt36mC1rvP+ZwU7cwzrbutsIpMSLxnTLycJ7wy7QvQzIytf7yrAcy7I8y7Rcy7Z8y7ic y7q8y7zcy778y8AczMI8zMRczMZ8zMiczMq8zJ6yIEGgbJagHd+kD5Axe0pxAmRSIzBAzcLAdNoU d4mBFNhcHtq8zV7CFdnEzdQ8Hr2wIfumbx8SFTcCztshz/Uszo3Bzd3kzN0cC+Uxz4gRz95RFRfy z/hs0P6wJdAMTsAwHv/hJOicIC9CI+gxFRMd0fjU0FzizrRnJrS30QRNJiJNfSlRffZUz2USzirB JORcINI8Jh+90vuE0oDxzsSgJZTXz+FxGwjNGE3+V08EEiA2Dc/r0R3uvNFFQdJJfc/M3NRO/dRQ HdVSPdVUXdVWfdVYndVavdVc3dUiUB+lUAw1UBqdJhEgANZEgNYpoNZpcBlsliJo7dYOYmM29tZg LdedhhEYAB3mcArRsQJqbQ1snRbe4Nd+XR+DTQ2wZtg9IBd3LRwUMQ7c0NfksNeVHdaU3RKaLRox ENeK3QGTzdmYnddrndg2gNeVLRQuAROTjdqpbQ7goNeG3QwFERPMwGa3TRl/DdtAwdjG0RbfcGO5 PdzD3WZBIdw+ESEL8du4LderbRrArdvJDd1jAdsX0Wan/dmtLdvS/dqfbRx6vdpvQR2uvd28bRn+ nRHbZD0TFvHX633Z5v3doZ3Z8V0asQ3ftS3bx2Ea/M3bxaHY8y3Zfc3eP6De3v3ciK3aqv3dAF7b 5d3fqS3YEvDerX0aZL1mr31jaeLe3K0T1H3dA97ehe3fEP7e3V3dAQ7enBHcpu0CBl7f3c3ZoZ3i buHgNq7f3n3ZOt7gJ87gF07gEb7jJ4Lj3E3i0XHfy80j803hJQ7hyWHit63g+S3kOfDiTZ7ZjG3g Ou4m4T3lGU7kXn7YV97h+N3jY17mOU7ZME4dRJ7kOL7mb+7bUI7mN07lOMATeM7iRT7aXm7Xdj7j Yc7aHf7fdB3lvR0T9h3dGY7c2K3oiH7gxYH+5Asu5RWu4W2i3hQR4Eke6dgNBS2ugMsR6qI+6qRe 6qZ+6qie6qq+6qze6q7+6rAO614967Re67Z+67ie67q+67ze675+B59OBr8kaDOWKpBlBK5tair3 dkZkfV9m7BRAf7pUOmwnZPBnfww27Q1Td3d359Bge9i1cdKu7bcG7XJW7Lln7SaX7apGbAXu5eBu aYjzfNFHZVBFX1Bl729GX65WVUg2RXJ078quQb2jRp4D8B00VU9VPfzOXldDZeJjRxG2dv2e3dCl ds0XZUn3eoqWablDV0rHOPD1cbgXM9MFe66UZ7hX8nFjd4z0ZCsTaIJzVeMeAgPPennD8cH+xEeW 1/KBw+2H03bssvInj1mth/KnRvQuf/SuBHXQJzxFH1utZ2zn7njyLkXZ02T11S89//FOz/Iw//VR f3mWYzRNFvS3N/aRB/Yi7ztQj/RFnwPxLnm0w/ZShTBlr2lpP1tcNvJk3/J73/TZ4vdLj/aZ8/du 9/ZM/z2V5m8sJjkplz28Y/T47vC9pPEilPWUz3FpZPgBb/SUNT0pZ0vu1XZuxO9Tg3IYDzuq3y9H B/RTr39cUPNUQPsFJPuQNey/TinBPgG230cq8PtVb2jXPifJ7mqD9HYnZvD2fmnk3u7dznbsDmVg dvFORl0bIPxg0GZzH2nw5/1dX/zdbu7+mEZphebxrOb8LtYHyZ7+4b7tMg88LVb5KDfzLvT5AD8v lr9DQT9nu3NZCGAKuvAMGsncjHU2+NrNncONZGmeaKqubMsR5HfJoeVRcbxheNd/PlpwRhEGexGa UUM8Kn08DFHzG1GpHCwWai16XeCweEwG32pGbhaobrOBsvNtyfNs4fVsPr7BT+dJUVeBdHqDGVoV SFV2UWWPkJGSXXmVi2t6lIt4bl97m0h3hp5vo4GjW4SqXKWDT3WpjJqTtLW2KkK5szmZl2mWonTC oZanxq+yUL+Vom3MX36ZyLG31da00UWAOmxoiHy8NRI7NgtwImdHas3lncrovjgzzb3+fIk7ilLy 6N3X/v8AAwocSLCgwYMIEypcyLChw4cQI0qcSLGiQhgWXYhI0a9aR4EfNYbMSFIMjJNr+Kk0l47g SC/0sCl8OfJlSprh+ukseYuAT01N9PVCaLPKtaLWcKJAWqxEt6C7eFZDiZGVVUcfyan8NA/cuK5f VfURRzYsoq/ntgpNO6XsNikswZolJ0gbOHzGQIBwhQ+v1BZVjebSipdTXiVBqTlS5+QTYxPBiDFO VHeI1WmVFwPL9wPZ4o2m8sXU/NdM375RQ6BNNW3O05t1DyVx7XTs5HrfxOIedtsw6M1Pbc/29UY4 5rOlyyS+eglTqWSaN/Ju7HncblL+11Flphf5cXHcj9d1/gwc+ujkZuSpH+rU8WWj4t/DdG+YfrHj v44fc08ePjXfoa2nX3ekobdCNkMIZ4Vaer3VIGhsiXOIOWT5ddZg0u1TCFrrrOTNg3qFYkE4FfID nhwEdsWUgSy2mJ6LMMYo418rzmjjjTjmqOOO7Lk0D49ABumQg2LUxw2FzrQn5JJMytTji0mCEmVq TVZpJS68nKYiiUxAuGCXFc4m15Vklklefk0hGOFmljVl5ptNvtbIhXbFJpl/2KkG555MyglUmqEZ ueFov/Fp6I2tYIdmnu6U50yNh0bK0zZanocihG+l1WGIknbqKYmfhiqqP5COaur+qaimquqqrLbq 6quwxirrrLTWimpgj5S6p64r6morJFTBViCRInkVooUcTfKack+uVmCjvxbkE67LsFcqZvodeFSu LTzXbbQGBZsMXZRoGZ6ijH5IWFmnVAoXmA2+y6Fd3r7T1pacgusPrsgRmO5wSmJ7Z4q1ybcKc0wY rOZNsiW8X7P6/vNEdWKWo5ijD1+W6bK5TbzExsYFaq19GPoaMRkTe6IyfwPbB50bAGanyKJYEZNG or39ezJAKSvThcC7AL0dy0PnzCh39yUtstAm7xyGHOxS6mFw67r126XW+aWpN/CKNqJZyN0mJbnv 4uv0qU2fkPbZbCtbKCTIti3+99x012333XjnrffefPft99+ABy744IQXbvjhiCeu+OKMN+7445BH LvnklFdu+eWYZ6755px37vnnoIcu+uikl2766ainrvrqrLeOuACwxw4A7BzQHrvss9/+wO20l4D7 7rxDwLsAJOjee+7A4z68Cb+PMPzyx0dPfO3TA59778EjL3z1yf++/PXEew8+9rqf8P343Dd/PvXb o+979uI3JD37x1svvPYoqF89+SrYvn/46Wuf+erHPgEacH4FtB//7lc/As6vgdMj3/4OGEDm/c9+ xYOgASmIPwemD4ATlN8F2+fB2uHPgh0cIQHfl8ITjpCFK3Qh91qIwRousIH+MnTeBTWoPQDujoP3 Q6ECZ2g9BNawhUa0Yfh66JAk+k+HGUzBEzG4wPz5sIhEPCL9sshDAZavhF6MIBG7SMUrDvGH2ANi /1TIRTOSEYkvVOLsmCjC7UGvfOPrXhvDiMfswZCN+hPiCfWYRyxOkXrfu6H/1gfHAqYReXH04/v6 SMkwJrCMNNyg7YrYxEia8Y9WhN8nYwjFJGJyknjU5BiV1zw59nCHH9ThF2NJx01q8ZZYvKQeqzjI B0pSjmKcYx2BOcNYkvKUVTwmCXeYQFKaMoeyFOMKeZjMURZzlY6MoB0PqMtsbhCZtOSgMjX4vywe xImfFGYuBbnOV64Ric3+3KMu3+hKKFqykd+cJi0feT1u3hOIYFzmN/HJTlv2c5g5TOQsU9lLa7oP keWUXiCjOM8PVnKgCWWl8cJ5S4UaNJOFbOgWN1rKX9qRl6jk5yBdx9KWuvSlMI2pTGdK09DdcaSt FN9NwdlKe0JUoqzE6EF3Gc1DQtKkyUOkUrd50kWCMIgmPZ9HZXfHCVbVot3MIFbRiFSCoHOlTJ1j QH1pQnZmdIu4HKpQQWpUC241qWG1pwQZWEFxhtOU8YNmXJUJ17660ZwC+eoxr5hOIxoVsAE9KloH W1jEehKsaOWqZNvpTbFqE4fx1Cte6ahXxaa1nYTtbEEEi1gmgnGWkKX+qCozOs7GDnC1fD1kaMnq 0zTaFrAEzaQDOUtG2eLWs5ad7Gf/AdSN9jSYIPSlb3ta0cga0oqrFeTzkivPWioyugrk5Fwz28Xi /hCS2EVga72oXY6O9rGDLa9WpVld1RITpwOUJGNhi9vnfTeo6IujdYN7RIVmtr+crKd9U5vf+y6R ngMhrfm2qU8JanOtiT2sD535WOkas74qDKI7zyhXButXn//tZVi7y0boZjepCA4sekuL4vZGr7L5 vHBkQRxi1ZLTsaXUcFvbylvf+jS8Hx7xPq+Z2hKWE6QGIS1DL3xRJXrvmgt9Mmr7S+S0KjmnRN6j kYNnvGwuuY2pLO7+EtVIUpwmFrzLZGin+FpTurG5zXCOs5znTOc627kWojQulhdJ1yg3WMqAdioE t+rRPh+3t1DWKFW5nOdArxK/J1XrotUc0kJzVc9D/etDu5rgAMaQwn5Vo0g5vGGh6s+hOv0womvr Wvr+073pfCVW8eppJut4yFaF5Y9/S9xas/DXoT0llf+JUmeaFtXH5u6Qbdzq95Ia1iu9rWRpbUJy 9tiRyaasCxVC4x9jm59f/a94q1y8ZFtb2naFcboveeNXezval403krsNXnDvM9vAHa5XpRlSyD7S oOFuakS9229hBtXa9V62k8GsaPai2o9RxWaHDypoibN7zAC/d8L100zwhND23SfOOHYpK2GQG5x/ CN8kNRkJam2vuuRmhbeBkatqWGN8zNBEbm7dm2Rd85y8fq0wsYM5bN/dOqEehvGZ1z3yKT5TkzJX p89HLVw0Z1rj/fz4d/XtD62b+sFXHzkNx23yEOY745qmur+nXk/gopTdUTe7j+GO8LADPetsVyeB A3LVp3dZ1Iw8K8d5vHUvK8/MNf+6nxs7ZUMeuuHJ1fvgGT5wsOuWqoZ3uMPvzPnOe/7zoA+96EdP +tKb/vSoT73qV8/61rv+9bCPvexnT/va2/72uM+97nfP+977/vfAD77wh0/84hv/+MhPvvKvkQA= OwA= ------------8FB252CD39B2CD31-- From ipcdn-bounces@ietf.org Tue Nov 07 22:25:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghe3L-0007kf-RC; Tue, 07 Nov 2006 22:24:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghe3J-0007gq-VA for ipcdn@ietf.org; Tue, 07 Nov 2006 22:24:37 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghe3I-0004Ys-BN for ipcdn@ietf.org; Tue, 07 Nov 2006 22:24:37 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id kA83OZBY018259 for ; Tue, 7 Nov 2006 20:24:35 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Nov 2006 20:24:34 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Changes incorporated in draft-ietf-ipcdn-pktc-signaling-12 Thread-Index: AcaP68+fwbfnjLoQQ7qQONaSPjyJBgBZbMrwAAIdfLAcYqCe8A== From: "Sumanth Channabasappa" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: a1dc446dc7ac353b90b60743d0e479e3 Subject: [ipcdn] Changes incorporated in draft-ietf-ipcdn-pktc-signaling-12 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipcdn-bounces@ietf.org Folks, The co-authors of the I-D titled "Network-Based Call Signaling (NCS) MIB for PacketCable and IPCablecom Multimedia Terminal Adapters (MTAs)" submitted draft-12 before the I-D Submission deadline and this email summarizes the changes.=20 As a note, it does contain technical changes in addition to the changes based on feedback received (thanks to those who provided comments). regards Sumanth (on behalf of the co-authors) Link: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-12.t xt ---------------------------------------------------------------------- 1. [Dan] The title of the document includes twice the word 'signaling' - is this necessary?=20 [Rich] I agree it seems to be redundant. I think occasionally folks refer to "NCS signaling", which is also a redundant term. [Sumanth] Agree; additionally removed redundant term 'NCS Signaling' elsewhere in the document ---------------------------------------------------------------------- ---------------------------------------------------------------------- 2. [Dan] idnits complains about un-used references:=20 - Unused Reference: 'ETSI-TS-101-909-4' is defined on line 3335, but not referenced' [ETSI-TS-101-909-4] ETSI TS 101 909-4:"Access and Terminals (AT);' - Unused Reference: 'ETSI-EN-300-324-1' is defined on line 3354, but not referenced ' [ETSI-EN-300-324-1] ETSI EN 300 324-1 V2.1.1 (2000-04):"V Interfaces' [Rich] These references do appear in the REFERENCE clauses of several objects each, e.g. pktcSigPulseSignalTable and pktcSigPulseSignalType. I suppose these two documents could be explicitly referenced in section 4, to make the idnits issue go away. [Sumanth] Can we ignore the idnits bug?=20 ---------------------------------------------------------------------- ---------------------------------------------------------------------- 3. [Dan] No need for the second paragraph in the Abstract. Anyway, this is repeated in a 'boilerplate standard' manner in the Introduction section. [Rich, PC] I agree. [Sumanth] Done ---------------------------------------------------------------------- From ipcdn-bounces@ietf.org Tue Nov 07 22:25:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghe3L-0007kf-RC; Tue, 07 Nov 2006 22:24:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghe3J-0007gq-VA for ipcdn@ietf.org; Tue, 07 Nov 2006 22:24:37 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghe3I-0004Ys-BN for ipcdn@ietf.org; Tue, 07 Nov 2006 22:24:37 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id kA83OZBY018259 for ; Tue, 7 Nov 2006 20:24:35 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Nov 2006 20:24:34 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Changes incorporated in draft-ietf-ipcdn-pktc-signaling-12 Thread-Index: AcaP68+fwbfnjLoQQ7qQONaSPjyJBgBZbMrwAAIdfLAcYqCe8A== From: "Sumanth Channabasappa" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: a1dc446dc7ac353b90b60743d0e479e3 Subject: [ipcdn] Changes incorporated in draft-ietf-ipcdn-pktc-signaling-12 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipcdn-bounces@ietf.org Folks, The co-authors of the I-D titled "Network-Based Call Signaling (NCS) MIB for PacketCable and IPCablecom Multimedia Terminal Adapters (MTAs)" submitted draft-12 before the I-D Submission deadline and this email summarizes the changes.=20 As a note, it does contain technical changes in addition to the changes based on feedback received (thanks to those who provided comments). regards Sumanth (on behalf of the co-authors) Link: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-12.t xt ---------------------------------------------------------------------- 1. [Dan] The title of the document includes twice the word 'signaling' - is this necessary?=20 [Rich] I agree it seems to be redundant. I think occasionally folks refer to "NCS signaling", which is also a redundant term. [Sumanth] Agree; additionally removed redundant term 'NCS Signaling' elsewhere in the document ---------------------------------------------------------------------- ---------------------------------------------------------------------- 2. [Dan] idnits complains about un-used references:=20 - Unused Reference: 'ETSI-TS-101-909-4' is defined on line 3335, but not referenced' [ETSI-TS-101-909-4] ETSI TS 101 909-4:"Access and Terminals (AT);' - Unused Reference: 'ETSI-EN-300-324-1' is defined on line 3354, but not referenced ' [ETSI-EN-300-324-1] ETSI EN 300 324-1 V2.1.1 (2000-04):"V Interfaces' [Rich] These references do appear in the REFERENCE clauses of several objects each, e.g. pktcSigPulseSignalTable and pktcSigPulseSignalType. I suppose these two documents could be explicitly referenced in section 4, to make the idnits issue go away. [Sumanth] Can we ignore the idnits bug?=20 ---------------------------------------------------------------------- ---------------------------------------------------------------------- 3. [Dan] No need for the second paragraph in the Abstract. Anyway, this is repeated in a 'boilerplate standard' manner in the Introduction section. [Rich, PC] I agree. [Sumanth] Done ---------------------------------------------------------------------- ---------------------------------------------------------------------- 4. [Dan] I believe that the following statement is confusing: This MIB module also utilizes the syntax definition of the=20 Differentiated Services Code Point (DSCP) from DIFFSERV-DSCP-TC=20 [RFC3289] for signaling MIB objects to allow for differentiation=20 between various types of traffic in the service provider network.=20 I would rather replace it with: This MIB module also utilizes the syntax definition of the=20 Differentiated Services Code Point (DSCP) TC from DIFFSERV-DSCP-TC=20 [RFC3289] for defining MIB objects that allow for differentiation=20 between various types of traffic in the service provider network.=20 [Rich, PC] I agree. [Sumanth] Done ---------------------------------------------------------------------- ---------------------------------------------------------------------- 5. [Dan] I could not understand what is meant by: This MIB module also utilizes SNMP management MIB architecture from=20 SNMP-FRAMEWORK-MIB [RFC3411].=20 [RW] I believe this refers to the fact that the MIB module imports SnmpAdminString as a TC for several MIB objects. Maybe the draft should just state that. [Sumanth] This was a legacy statement that could not be traced and has been removed ---------------------------------------------------------------------- ---------------------------------------------------------------------- 6. [Dan] pktcSigNotification=20 =20 pktcSigNotification - this object is used for signaling notification=20 and reserved for future use.=20 This is not an object, but just an OID. Needs not any explanation [RW] I agree. [Sumanth] Removed ---------------------------------------------------------------------- ---------------------------------------------------------------------- 7. [Dan] DESCRIPTION clause of pktcSigDevSilenceSuppression " This object specifies if the device is capable of=20 silence suppression (Voice Activity Detection)." =20 Better say:=20 " This object specifies if the device is capable of=20 silence suppression (as result of Voice Activity Detection)." =20 [RW] I agree. [sumanth] Done ---------------------------------------------------------------------- ---------------------------------------------------------------------- 8. [Dan] DESCRIPTION clause of pktcSigDevCidSigProtocol =20 "This object identifies the subscriber line protocol used=20 for signaling on-hook caller id information. Different=20 countries define different caller id signaling protocols to=20 support caller identification. Frequency shift keying (FSK)=20 is most commonly used. Dual tone multi-frequency (DTMF)=20 is an alternative."=20 This object has a MAX-ACCESS clause of read-write. The DESCRIPTION should rather say: "This object is used to configure the subscriber line protocol used for signaling on-hook caller id information. Different countries define different caller id signaling protocols to support caller identification.=20 - setting this object at a value fsk(1) sets the subscriber line protocol to be Frequency Shift Keying (FSK)=20 - setting this object at a value dtmf(2) sets the subscriber line protocol to be Dual tone multi-frequency (DTMF)."=20 [RW] I agree. [Sumanth] Done ---------------------------------------------------------------------- ---------------------------------------------------------------------- 9. [Dan] I believe that pktcSignalingVersion has a significance only for pktcSignalingType ncs(3). If true, this needs to be mentioned in the object DESCRIPTION clause.=20 [RW] Or alternatively, the pktcSignalingVersion is relevant only for a particular pktcSignalingType value. As an example, the semantics of pktcSignalingVersion "2.0" would depend on the value of pktcSignalingType, say ncs(3) or sip(4) -- making up the latter enumeration. :^) [Sumanth] This was meant to indicate allow for other protocols to reuse the MIB (hence the 'other'). Can we leave it as-is? ------------------------------------ ---------------------------------------------------------------------- 4. [Dan] I believe that the following statement is confusing: This MIB module also utilizes the syntax definition of the=20 Differentiated Services Code Point (DSCP) from DIFFSERV-DSCP-TC=20 [RFC3289] for signaling MIB objects to allow for differentiation=20 between various types of traffic in the service provider network.=20 I would rather replace it with: This MIB module also utilizes the syntax definition of the=20 Differentiated Services Code Point (DSCP) TC from DIFFSERV-DSCP-TC=20 [RFC3289] for defining MIB objects that allow for differentiation=20 between various types of traffic in the service provider network.=20 [Rich, PC] I agree. [Sumanth] Done ---------------------------------------------------------------------- ---------------------------------------------------------------------- 5. [Dan] I could not understand what is meant by: This MIB module also utilizes SNMP management MIB architecture from=20 SNMP-FRAMEWORK-MIB [RFC3411].=20 [RW] I believe this refers to the fact that the MIB module imports SnmpAdminString as a TC for several MIB objects. Maybe the draft should just state that. [Sumanth] This was a legacy statement that could not be traced and has been removed ---------------------------------------------------------------------- ---------------------------------------------------------------------- 6. [Dan] pktcSigNotification=20 =20 pktcSigNotification - this object is used for signaling notification=20 and reserved for future use.=20 This is not an object, but just an OID. Needs not any explanation [RW] I agree. [Sumanth] Removed ---------------------------------------------------------------------- ---------------------------------------------------------------------- 7. [Dan] DESCRIPTION clause of pktcSigDevSilenceSuppression " This object specifies if the device is capable of=20 silence suppression (Voice Activity Detection)." =20 Better say:=20 " This object specifies if the device is capable of=20 silence suppression (as result of Voice Activity Detection)." =20 [RW] I agree. [sumanth] Done ---------------------------------------------------------------------- ---------------------------------------------------------------------- 8. [Dan] DESCRIPTION clause of pktcSigDevCidSigProtocol =20 "This object identifies the subscriber line protocol used=20 for signaling on-hook caller id information. Different=20 countries define different caller id signaling protocols to=20 support caller identification. Frequency shift keying (FSK)=20 is most commonly used. Dual tone multi-frequency (DTMF)=20 is an alternative."=20 This object has a MAX-ACCESS clause of read-write. The DESCRIPTION should rather say: "This object is used to configure the subscriber line protocol used for signaling on-hook caller id information. Different countries define different caller id signaling protocols to support caller identification.=20 - setting this object at a value fsk(1) sets the subscriber line protocol to be Frequency Shift Keying (FSK)=20 - setting this object at a value dtmf(2) sets the subscriber line protocol to be Dual tone multi-frequency (DTMF)."=20 [RW] I agree. [Sumanth] Done ---------------------------------------------------------------------- ---------------------------------------------------------------------- 9. [Dan] I believe that pktcSignalingVersion has a significance only for pktcSignalingType ncs(3). If true, this needs to be mentioned in the object DESCRIPTION clause.=20 [RW] Or alternatively, the pktcSignalingVersion is relevant only for a particular pktcSignalingType value. As an example, the semantics of pktcSignalingVersion "2.0" would depend on the value of pktcSignalingType, say ncs(3) or sip(4) -- making up the latter enumeration. :^) [Sumanth] This was meant to indicate allow for other protocols to reuse the MIB (hence the 'other'). Can we leave it as-is? ---------------------------------------------------------------------- ---------------------------------------------------------------------- 10. [Dan] It is not clear what value reserved(2) means in the PktcSigType TC. 'for future use' does not make too much sense, if this value will become meaningful in the future you cannot change the semantics of this enumerated value. I suggest to skip this value and use only other and ncs [RW] I agree. For example, we could not decide after publication that 'reserved(2)' really meant 'sip'. [sumanth] Done ---------------------------------------------------------------------- ---------------------------------------------------------------------- 11. [Dan] It is not clear what level of interoperability can the pktcSignalingVendorExtension object offer if the encoded string is vendor specific. I suggest to take this oibject out.=20 [RW] I agree with the concern, but I wonder if this object can be salvaged. Authors: is the encoding of this object equivalent to the encoding of the 'VendorExtensionParameter' on page 134 of the NCS specification, ? That MGCP protocol syntax has a well-defined encoding, that could be leveraged for the value of this MIB object as well. [Dan] I suggest that at 11 you document better the object and mention the format that you referred in your explanation in the DESCRIPTION clause. [Sumanth] How about we say: " The syntax for this MIB Object in ABNF ([RFC 4234]) is specified =20 to be zero or more occurrences of vendor extensions, as follows: pktcSignalingVendorExtension =3D *["X" ("-"/"+") 1*6(ALPHA / DIGIT) ";"] " If so, its done :)) ---------------------------------------------------------------------- ---------------------------------------------------------------------- 12. [Dan] It does not make sense to specify DEFVAL clauses for read-only objects (pktcSigDefNcsReceiveUdpPort, pktcSigPowerRingFrequency). If configuration by SNMP is not allowed, setting the instrumentation at the desired state has not any relation with the SNMP agent.=20 [RW] I tend to agree, although this "overcommunication" approach has been used in other drafts that have originated in this WG before. As one specific example see 'pktcMtaDevDhcpServerAddressType' in -- this draft is on the RFC Editor's Queue intended for proposed standard; it was approved last February. [Dan] I suggest that at 12 you rather than using DEFVAL you mention in the DESCRIPTION that you expect an agent to return those values after initialization, but it should be clear that such an action is performed at the instrumentation level, and not at the level of the SNMP agent. (what happens if the value is read by CLI?) [Sumanth] Agree with Dan; I removed the DEFVAL and added a statement to indicate the indicated default values, unless modified via MTA configuration. Does that make sense? ---------------------------------------------------------------------- ---------------------------------------------------------------------- 13. [Dan] Inconsistent use of keywords in the DESCRIPTION clause of pktcSigDevToneDbLevel. Actually I believe that there is no place here for a MUST. Instead of 'This MIB Object MUST reflect the desired level...' rather say 'This MIB object reflects ...' [RW] I agree. [Sumanth] done ---------------------------------------------------------------------- ---------------------------------------------------------------------- 14. [Dan] In several places the term 'SNMP Management Station' is being used. I prefer 'SNMP Manager application'.=20 [RW] I tend to agree, especially after reading sections 7.5 and 7.7 of RFC 3410, and seeing RFC 3413 "Simple Network Management Protocol (SNMP) Applications". [Sumanth] Corrected ---------------------------------------------------------------------- ---------------------------------------------------------------------- 15. [Satish]=20 The MIB pktcSigDevToneDbLevel defined in draft-11 has range (-250..-30) w---------------------------------- ---------------------------------------------------------------------- 10. [Dan] It is not clear what value reserved(2) means in the PktcSigType TC. 'for future use' does not make too much sense, if this value will become meaningful in the future you cannot change the semantics of this enumerated value. I suggest to skip this value and use only other and ncs [RW] I agree. For example, we could not decide after publication that 'reserved(2)' really meant 'sip'. [sumanth] Done ---------------------------------------------------------------------- ---------------------------------------------------------------------- 11. [Dan] It is not clear what level of interoperability can the pktcSignalingVendorExtension object offer if the encoded string is vendor specific. I suggest to take this oibject out.=20 [RW] I agree with the concern, but I wonder if this object can be salvaged. Authors: is the encoding of this object equivalent to the encoding of the 'VendorExtensionParameter' on page 134 of the NCS specification, ? That MGCP protocol syntax has a well-defined encoding, that could be leveraged for the value of this MIB object as well. [Dan] I suggest that at 11 you document better the object and mention the format that you referred in your explanation in the DESCRIPTION clause. [Sumanth] How about we say: " The syntax for this MIB Object in ABNF ([RFC 4234]) is specified =20 to be zero or more occurrences of vendor extensions, as follows: pktcSignalingVendorExtension =3D *["X" ("-"/"+") 1*6(ALPHA / DIGIT) ";"] " If so, its done :)) ---------------------------------------------------------------------- ---------------------------------------------------------------------- 12. [Dan] It does not make sense to specify DEFVAL clauses for read-only objects (pktcSigDefNcsReceiveUdpPort, pktcSigPowerRingFrequency). If configuration by SNMP is not allowed, setting the instrumentation at the desired state has not any relation with the SNMP agent.=20 [RW] I tend to agree, although this "overcommunication" approach has been used in other drafts that have originated in this WG before. As one specific example see 'pktcMtaDevDhcpServerAddressType' in -- this draft is on the RFC Editor's Queue intended for proposed standard; it was approved last February. [Dan] I suggest that at 12 you rather than using DEFVAL you mention in the DESCRIPTION that you expect an agent to return those values after initialization, but it should be clear that such an action is performed at the instrumentation level, and not at the level of the SNMP agent. (what happens if the value is read by CLI?) [Sumanth] Agree with Dan; I removed the DEFVAL and added a statement to indicate the indicated default values, unless modified via MTA configuration. Does that make sense? ---------------------------------------------------------------------- ---------------------------------------------------------------------- 13. [Dan] Inconsistent use of keywords in the DESCRIPTION clause of pktcSigDevToneDbLevel. Actually I believe that there is no place here for a MUST. Instead of 'This MIB Object MUST reflect the desired level...' rather say 'This MIB object reflects ...' [RW] I agree. [Sumanth] done ---------------------------------------------------------------------- ---------------------------------------------------------------------- 14. [Dan] In several places the term 'SNMP Management Station' is being used. I prefer 'SNMP Manager application'.=20 [RW] I tend to agree, especially after reading sections 7.5 and 7.7 of RFC 3410, and seeing RFC 3413 "Simple Network Management Protocol (SNMP) Applications". [Sumanth] Corrected ---------------------------------------------------------------------- ---------------------------------------------------------------------- 15. [Satish]=20 The MIB pktcSigDevToneDbLevel defined in draft-11 has range (-250..-30) with default value as -40dBm. Normal dial tone is at -13dB (means -130dBm). Current default value is a too loud signal. I would recommend to change the defailt to -120 along with the range to (-250..-110) [Eugene]=20 This proposal looks reasonable given the fact that POTS specification seems to not require a full existing range of (-250, -30). The proposed default value is also reasonable. [Sumanth] Done ---------------------------------------------------------------------- ---------------------------------------------------------------------- =20 16. [Eugene] Refer to " Issues with Tone Generation in Signaling MIB draft-11 (Eugene, v1).doc" Summary: Japan's "NTT Telephone service interfaces, edition 5" Specification defines two call waiting tones - "Incoming Identification Tone" (IIT) and "Specific Incoming Identification Tone" (SIIT) containing the following tone sequence: Either of these tones corresponds to the following tone generation schema: 1. 16 Hz is modulated to carry the 400 Hz signal, ModulationRate within 85%, on for 500msec, at -25 dBm or more but less than -14 dBm 2. 16 Hz is modulated to carry the 400 Hz signal, off for 0 ~ 4 secs 3. 400 Hz not modulated, on for 50 ms at -25 dBm or more but less than -14 dBm 4. 400 Hz not modulated, off for 450ms=20 5. 400 Hz not modulated, on for 50 ms at -25 dBm or more but less than -14 dBm 6. 400 Hz not modulated, off for 3450ms ([4000 - (50+450+50)]) 7. Steps 3 thru 6 are repeated. As standard requires, to generate either of those call waiting tones, the tone sequence should contain non-repetitive frequency group (step-1 + step-2) immediately followed by a repetitive frequency group (step-3 + step-4 + step-3 + step-4 + step-5) with the duration of 4000 msec in total.=20 The current composition of the Tone Generation MIB Tables in draft-11 ("pktcSigDevToneTable" and "pktcSigDevMultiFreqToneTable") is such that it can accommodate either non-repetitive tone sequence or repetitive tone sequence, and does not allow the mixture of those. Proposal: To address the problem, the composition of the Tone Generation Tables defining various Tone Types should allow for the combination of the repetitive and non-repetitive parts in the definition of the particular tone.=20 In the current draft-11, the "pktcSigDevToneTable" MIB Table is defined in such a way that it allows only for one row for each particular tone type. By doing so, this table can define only either the repetitive tone (when pktcSigDevToneWholeToneRepeatCount > 0) or non-repetitive tone (when pktcSigDevToneWholeToneRepeatCount =3D=3D 0). Such composition of = the "pktcSigDevToneTable" MIB Table excludes the possibility for the tone type to be represented by a mixture of non-repetitive and repetitive parts. To allow for the various definitions of the Tone Types, the composition of the "pktcSigDevToneTable" MIB Table should be expanded.=20 [Sumanth] Incorporated ---------------------------------------------------------------------- ---------------------------------------------------------------------- 17. [Satish] Requested clarification to the MIB Object 'pktcSigDevR5Cadence' to indicate that it is a non-repeatable signal. [Sumanth] The request in return is to clarify this in the "L Package" specification ---------------------------------------------------------------------- ---------------------------------------------------------------------- 18. [Eugene] Add clarification to 'pktcSigDevToneSteady' "If pktcSigDevToneTable contains multiple rows with this=20 Object set to 'true', the steady tone is applied to the=20 last repeating frequency group of the tone." [Sumanth] Done ---------------------------------------------------------------------- =20 =20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Nov 07 22:25:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghe3M-0007kx-1m; Tue, 07 Nov 2006 22:24:40 -0500 Received: from [10ith default value as -40dBm. Normal dial tone is at -13dB (means -130dBm). Current default value is a too loud signal. I would recommend to change the defailt to -120 along with the range to (-250..-110) [Eugene]=20 This proposal looks reasonable given the fact that POTS specification seems to not require a full existing range of (-250, -30). The proposed default value is also reasonable. [Sumanth] Done ---------------------------------------------------------------------- ---------------------------------------------------------------------- =20 16. [Eugene] Refer to " Issues with Tone Generation in Signaling MIB draft-11 (Eugene, v1).doc" Summary: Japan's "NTT Telephone service interfaces, edition 5" Specification defines two call waiting tones - "Incoming Identification Tone" (IIT) and "Specific Incoming Identification Tone" (SIIT) containing the following tone sequence: Either of these tones corresponds to the following tone generation schema: 1. 16 Hz is modulated to carry the 400 Hz signal, ModulationRate within 85%, on for 500msec, at -25 dBm or more but less than -14 dBm 2. 16 Hz is modulated to carry the 400 Hz signal, off for 0 ~ 4 secs 3. 400 Hz not modulated, on for 50 ms at -25 dBm or more but less than -14 dBm 4. 400 Hz not modulated, off for 450ms=20 5. 400 Hz not modulated, on for 50 ms at -25 dBm or more but less than -14 dBm 6. 400 Hz not modulated, off for 3450ms ([4000 - (50+450+50)]) 7. Steps 3 thru 6 are repeated. As standard requires, to generate either of those call waiting tones, the tone sequence should contain non-repetitive frequency group (step-1 + step-2) immediately followed by a repetitive frequency group (step-3 + step-4 + step-3 + step-4 + step-5) with the duration of 4000 msec in total.=20 The current composition of the Tone Generation MIB Tables in draft-11 ("pktcSigDevToneTable" and "pktcSigDevMultiFreqToneTable") is such that it can accommodate either non-repetitive tone sequence or repetitive tone sequence, and does not allow the mixture of those. Proposal: To address the problem, the composition of the Tone Generation Tables defining various Tone Types should allow for the combination of the repetitive and non-repetitive parts in the definition of the particular tone.=20 In the current draft-11, the "pktcSigDevToneTable" MIB Table is defined in such a way that it allows only for one row for each particular tone type. By doing so, this table can define only either the repetitive tone (when pktcSigDevToneWholeToneRepeatCount > 0) or non-repetitive tone (when pktcSigDevToneWholeToneRepeatCount =3D=3D 0). Such composition of = the "pktcSigDevToneTable" MIB Table excludes the possibility for the tone type to be represented by a mixture of non-repetitive and repetitive parts. To allow for the various definitions of the Tone Types, the composition of the "pktcSigDevToneTable" MIB Table should be expanded.=20 [Sumanth] Incorporated ---------------------------------------------------------------------- ---------------------------------------------------------------------- 17. [Satish] Requested clarification to the MIB Object 'pktcSigDevR5Cadence' to indicate that it is a non-repeatable signal. [Sumanth] The request in return is to clarify this in the "L Package" specification ---------------------------------------------------------------------- ---------------------------------------------------------------------- 18. [Eugene] Add clarification to 'pktcSigDevToneSteady' "If pktcSigDevToneTable contains multiple rows with this=20 Object set to 'true', the steady tone is applied to the=20 last repeating frequency group of the tone." [Sumanth] Done ---------------------------------------------------------------------- =20 =20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Nov 07 22:25:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghe3M-0007kx-1m; Tue, 07 Nov 2006 22:24:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghe3K-0007j9-Op for ipcdn@ietf.org; Tue, 07 Nov 2006 22:24:38 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghe3J-0004Yw-CY for ipcdn@ietf.org; Tue, 07 Nov 2006 22:24:38 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id kA83OauM018262 for ; Tue, 7 Nov 2006 20:24:36 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Nov 2006 20:24:35 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Changes incorporated in draft-ietf-ipcdn-pktc-eventmess-09 Thread-Index: AcWh/HKIom44+HHgQGa23DAUEop9nw+NasHQSKwzPgA= From: "Sumanth Channabasappa" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Subject: [ipcdn] Changes incorporated in draft-ietf-ipcdn-pktc-eventmess-09 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipcdn-bounces@ietf.org Folks, =20 Just as an update, 'draft-ietf-ipcdn-pktc-eventmess-09' was submitted before the I-D submission deadline and this email summarizes the changes from the previous revision.=20 As a note, there were no technical changes made, but an attempt was made to address the comments received from experts received on this list (thanks). regards Sumanth (on behalf of the co-authors) ----------------------------------------------------------------------- #0=20 My personal comment is that we need to clean up the "nits" caught on in draft 09, subsequent to completion of the WGLC. These appear to be caused mostly by minor document formatting issues, especially the "missing sections" that are in fact present in the latest draft. [Sumanth] Fixed (please check)?=20 ----------------------------------------------------------------------- ----------------------------------------------------------------------- 1) Are you using nroff? The spacing of section titles is weird. Also, the online idnits tool still complains that page 4 is longer than it should be. It also complains that there is no Security Considerations or IANA Considerations sections, and I suspect this relates to the formatting of section titles. [Sumanth] Fixed (please check)? ----------------------------------------------------------------------- ----------------------------------------------------------------------- 2) RFC3164 is informational, and should be listed as an Informative not Normative Reference, if I remember the rules correctly. [Sumanth] Fixed (please check)? ----------------------------------------------------------------------- ----------------------------------------------------------------------- =20 3) PKT-SP-EVEMIB1.5 went from a January 2006 date to an August 2005 date. Is that correct? [Sumanth] Yes, it was incorrect in the earlier revision (should have been January 2005) ----------------------------------------------------------------------- ----------------------------------------------------------------------- 4) pktcDevEvLogEnterprise is defined with=20 SYNTAX Unsigned32(1.. 2147483648)=20 Why? I looked at the IANA Enterprise number list and saw no restriction to this range. Unsigned32 allows values (0 .91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghe3K-0007j9-Op for ipcdn@ietf.org; Tue, 07 Nov 2006 22:24:38 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghe3J-0004Yw-CY for ipcdn@ietf.org; Tue, 07 Nov 2006 22:24:38 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id kA83OauM018262 for ; Tue, 7 Nov 2006 20:24:36 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Nov 2006 20:24:35 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Changes incorporated in draft-ietf-ipcdn-pktc-eventmess-09 Thread-Index: AcWh/HKIom44+HHgQGa23DAUEop9nw+NasHQSKwzPgA= From: "Sumanth Channabasappa" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Subject: [ipcdn] Changes incorporated in draft-ietf-ipcdn-pktc-eventmess-09 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipcdn-bounces@ietf.org Folks, =20 Just as an update, 'draft-ietf-ipcdn-pktc-eventmess-09' was submitted before the I-D submission deadline and this email summarizes the changes from the previous revision.=20 As a note, there were no technical changes made, but an attempt was made to address the comments received from experts received on this list (thanks). regards Sumanth (on behalf of the co-authors) ----------------------------------------------------------------------- #0=20 My personal comment is that we need to clean up the "nits" caught on in draft 09, subsequent to completion of the WGLC. These appear to be caused mostly by minor document formatting issues, especially the "missing sections" that are in fact present in the latest draft. [Sumanth] Fixed (please check)?=20 ----------------------------------------------------------------------- ----------------------------------------------------------------------- 1) Are you using nroff? The spacing of section titles is weird. Also, the online idnits tool still complains that page 4 is longer than it should be. It also complains that there is no Security Considerations or IANA Considerations sections, and I suspect this relates to the formatting of section titles. [Sumanth] Fixed (please check)? ----------------------------------------------------------------------- ----------------------------------------------------------------------- 2) RFC3164 is informational, and should be listed as an Informative not Normative Reference, if I remember the rules correctly. [Sumanth] Fixed (please check)? ----------------------------------------------------------------------- ----------------------------------------------------------------------- =20 3) PKT-SP-EVEMIB1.5 went from a January 2006 date to an August 2005 date. Is that correct? [Sumanth] Yes, it was incorrect in the earlier revision (should have been January 2005) ----------------------------------------------------------------------- ----------------------------------------------------------------------- 4) pktcDevEvLogEnterprise is defined with=20 SYNTAX Unsigned32(1.. 2147483648)=20 Why? I looked at the IANA Enterprise number list and saw no restriction to this range. Unsigned32 allows values (0 .. 2^32-1) i.e. (0 .. 4294967295) pktcDevEventDescrEnterprise does not have the same range as pktcDevEvLogEnterprise. [S] Corrected the ranges.=20 ----------------------------------------------------------------------- ----------------------------------------------------------------------- 5) pktcDevEvLogIndex is not allowed to exceed 2^31. Why? (not that it is likely to reach a number higher than this, but the Unsigned32 can support up to 2^32-1. And is there a reason for not supporting the 0 low-end of the range? [Sumanth]=20 The reason for not supporting zero is based on the recommendation from RFC4181: - For integer-valued objects that appear in an INDEX clause or for integer-valued TCs that are to be used in an index column: - Unsigned32 with a range that excludes zero is RECOMMENDED for most index objects. It is acceptable to include zero in the range when it is semantically significant or when it is used as the index value for a unique row with special properties. Such usage SHOULD be clearly documented in the DESCRIPTION clause. The reason for the upper bound of 2^32 - 1 was based on the conclusion reached by the co-authors; but it is now modified to allow for the full range ----------------------------------------------------------------------- ----------------------------------------------------------------------- 6) RFC3164 is Informational, rather than standards-track. It might be better to use references based on the draft-ietf-syslog-protocol-17.txt, also in WGLC and about to be submitted for standards track. [Sumanth] Fixed ----------------------------------------------------------------------- ----------------------------------------------------------------------- 7) Is there a reason you changed the textual convention to be mib module specific? Since it uses values defined in RFC3164, would it be good to make this a generic textual convention?=20 An alternative would be to use the SyslogSeverity Textual Convention defined in the draft-ietf-syslog-device-mib-09.txt, which is in WGLC and about to be submitted for standards track. RFC3164 is Informational, rather than standards-track. Its references are based on the about-to-be standards track syslog-protocol-17 document. [Sumanth] Good comment and yes, it is done ----------------------------------------------------------------------- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn .. 2^32-1) i.e. (0 .. 4294967295) pktcDevEventDescrEnterprise does not have the same range as pktcDevEvLogEnterprise. [S] Corrected the ranges.=20 ----------------------------------------------------------------------- ----------------------------------------------------------------------- 5) pktcDevEvLogIndex is not allowed to exceed 2^31. Why? (not that it is likely to reach a number higher than this, but the Unsigned32 can support up to 2^32-1. And is there a reason for not supporting the 0 low-end of the range? [Sumanth]=20 The reason for not supporting zero is based on the recommendation from RFC4181: - For integer-valued objects that appear in an INDEX clause or for integer-valued TCs that are to be used in an index column: - Unsigned32 with a range that excludes zero is RECOMMENDED for most index objects. It is acceptable to include zero in the range when it is semantically significant or when it is used as the index value for a unique row with special properties. Such usage SHOULD be clearly documented in the DESCRIPTION clause. The reason for the upper bound of 2^32 - 1 was based on the conclusion reached by the co-authors; but it is now modified to allow for the full range ----------------------------------------------------------------------- ----------------------------------------------------------------------- 6) RFC3164 is Informational, rather than standards-track. It might be better to use references based on the draft-ietf-syslog-protocol-17.txt, also in WGLC and about to be submitted for standards track. [Sumanth] Fixed ----------------------------------------------------------------------- ----------------------------------------------------------------------- 7) Is there a reason you changed the textual convention to be mib module specific? Since it uses values defined in RFC3164, would it be good to make this a generic textual convention?=20 An alternative would be to use the SyslogSeverity Textual Convention defined in the draft-ietf-syslog-device-mib-09.txt, which is in WGLC and about to be submitted for standards track. RFC3164 is Informational, rather than standards-track. Its references are based on the about-to-be standards track syslog-protocol-17 document. [Sumanth] Good comment and yes, it is done ----------------------------------------------------------------------- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From akstcgdarmmnsdgs@gdarm.com Wed Nov 08 02:11:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghhay-0004XO-HU; Wed, 08 Nov 2006 02:11:36 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghhay-0005gK-Fk; Wed, 08 Nov 2006 02:11:36 -0500 Received: from [12.42.193.114] (helo=mail.eohrealty.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ghhav-0007IZ-20; Wed, 08 Nov 2006 02:11:34 -0500 Received: from 217.160.226.100 (HELO mx00.1and1.com) by lists.ietf.org with esmtp (G,+3S40G2.B Q67X) id 2U0:+8-=WH;N@-,0 for ipcdn-archive@lists.ietf.org; Wed, 8 Nov 2006 07:11:32 +0420 Message-ID: <01c70305$1e4cd4e0$6c822ecf@akstcgdarmmnsdgs> From: "Brandy Rosales" To: Subject: Fw: Date: Wed, 8 Nov 2006 07:11:32 +0420 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 X-Spam-Score: 3.9 (+++) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 "THESUBWAY.COM" PUT MPRG ON THIER �HOT STOCKS� LIST AFTER WILLIAM MORRIS AGENCY ANNOUNCED IT WILL BE SELLING RIGHTS TO NEW SUTHERLAND MOVIE! Company: The Motion Picture Group Inc. STOCK: MP RG Price: $0.32 UP Today Vol um e Ex pe ct ations: Huge Time to move fast. HUGE announcements on MPRG today. MPRG announced that William Morris Agency, the worlds largest and most diverse talent agency will be selling the rights to the new Keifer Sutherland movie at the 2006 American Film Market. That market closes on the 8th so this deal will be done by end of tomorrow. This is so hot, everyone os getting in while they can and the market watchers are labeling this as the next winner. Watch the trailer at "www.itrustyoutokillmethemovie.com" and get in on MPRG first thing Wed, November 08, 2006. I hope it was a helper news. I'll email or fax you later next week. Brandy Rosales. day, in such dirty weather, and by herself, was almost incredible to mrs. hurst and miss bingley; and "my dear brother, elizabeth's astonishment was beyond expression. she stared, coloured, doubted, and was silent. conjectures, on this interesting subject, by its repeated discussion, no other could detain them from it be justified in devoting too much of our time to music, for there are certainly other things to be "my father is gone to london, and jane has written to beg my uncle's immediate assistance; and "i have often observed how little young ladies are interested by books of a serious stamp, though before, and a positive engagement made of his meeting some of the gentlemen at pemberley before "i can easily believe it. you thought me then devoid of every proper feeling, i am sure you did. and publicly canvassed; and everybody was pleased to know how much they had always disliked mr. From ipcdn-bounces@ietf.org Tue Nov 21 18:52:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmfPi-0000AE-EQ; Tue, 21 Nov 2006 18:52:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmfPh-0000A9-Vo for ipcdn@ietf.org; Tue, 21 Nov 2006 18:52:29 -0500 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmfPf-0007lV-N0 for ipcdn@ietf.org; Tue, 21 Nov 2006 18:52:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Nov 2006 18:51:48 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DOCSIS Cable Device MIB and downref normative references Thread-Index: AccNyAKSZvOgJft5TtWjuyVCnx0A1w== From: "Woundy, Richard" To: X-OriginalArrivalTime: 21 Nov 2006 23:52:10.0604 (UTC) FILETIME=[0F61DAC0:01C70DC8] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: jfm@cablelabs.com, "Woundy, Richard" Subject: [ipcdn] DOCSIS Cable Device MIB and downref normative references X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipcdn-bounces@ietf.org Folks, In the process of trying to publish the updated DOCSIS Cable Device MIB, ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-11.txt, we have identified five "downref" normative references that must be fixed prior to publication. As RFC 3967 explains: IETF procedures generally require that a standards track RFC may not have a normative reference to another standards track document at a lower maturity level or to a non standards track specification (other than specifications from other standards bodies). For example, a standards track document may not have a normative reference to an informational RFC. Per guidance from our Area Director, there are two ways to fix these downref normative references: 1. Move the references to the informative references section, with WG consensus, or 2. Explain each downref normative reference in the draft (per RFC 3967), and perform another IETF Last Call. My recommendation (both as co-author and as co-chair) is to move the five references to the informative references section, and complete publication of this draft as an RFC. *** If you disagree with this recommendation, please reply to me and the IPCDN mailing list by Friday December 1. Here are the results of the new IETF draft/RFC dependency tool, as run against the latest draft: http://rtg.ietf.org/~fenner/ietf/deps/index.cgi?doc=3Ddraft-ietf-ipcdn-de= v ice-mibv2. The tool identifies normative references to five Informational RFCs: [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC 1858, October 1995. [RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. [RFC3128] Miller, I., "Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)", RFC 3128, June 2001. [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001. [RFC3617] Lear, E., "Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP)", RFC 3617, October 2003. The Security Considerations (section 6) recommends implementation of RFC 1858 (Informational) and RFC 3128 (Informational) to prevent the "tiny fragment" and "overlapping fragment" attacks, but does not mandate them. DOCSIS specifies the use of TFTP (RFC 1350 - Standard) for file transfers, but this MIB module enables implementation of HTTP 1.0 (RFC 1945 - Informational) or HTTP 1.1 (RFC 2616 - Draft Standard) for file transfers as well. See section 3.2.1 of the draft for a complete explanation. The TFTP URI (RFC 3617 - Informational) is referenced by docsDevServerConfigTftpAddress, but the syntax of the the object is an InetAddress, and is not dependent on RFC 3617. SYSLOG (RFC 3164) is one of several possible event notification mechanisms supported by this MIB module. -- Rich _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Nov 22 05:03:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmowM-0000sV-Jn; Wed, 22 Nov 2006 05:02:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmowL-0000sQ-Mn for ipcdn@ietf.org; Wed, 22 Nov 2006 05:02:49 -0500 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmowK-0001u4-CK for ipcdn@ietf.org; Wed, 22 Nov 2006 05:02:49 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id kAMA2hei028117; Wed, 22 Nov 2006 04:02:43 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 22 Nov 2006 11:02:42 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550AF7F5D3@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Woundy, Richard" , ipcdn@ietf.org Subject: RE: [ipcdn] DOCSIS Cable Device MIB and downref normative referen ces Date: Wed, 22 Nov 2006 11:02:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: jfm@cablelabs.com X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipcdn-bounces@ietf.org I support moving these 5 references from the normative to the informative section. Bert > -----Original Message----- > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > Sent: Wednesday, November 22, 2006 00:52 > To: ipcdn@ietf.org > Cc: jfm@cablelabs.com; Woundy, Richard > Subject: [ipcdn] DOCSIS Cable Device MIB and downref normative > references > > > Folks, > > In the process of trying to publish the updated DOCSIS Cable > Device MIB, > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mib > v2-11.txt, > we have identified five "downref" normative references that must be > fixed prior to publication. > > As RFC 3967 explains: > > IETF procedures generally require that a standards track > RFC may not > have a normative reference to another standards track document at a > lower maturity level or to a non standards track > specification (other > than specifications from other standards bodies). For example, a > standards track document may not have a normative reference to an > informational RFC. > > Per guidance from our Area Director, there are two ways to fix these > downref normative references: > > 1. Move the references to the informative references section, with WG > consensus, or > > 2. Explain each downref normative reference in the draft (per > RFC 3967), > and perform another IETF Last Call. > > My recommendation (both as co-author and as co-chair) is to move the > five references to the informative references section, and complete > publication of this draft as an RFC. > > *** If you disagree with this recommendation, please reply to > me and the > IPCDN mailing list by Friday December 1. > > Here are the results of the new IETF draft/RFC dependency tool, as run > against the latest draft: > http://rtg.ietf.org/~fenner/ietf/deps/index.cgi?doc=draft-ietf -ipcdn-dev ice-mibv2. The tool identifies normative references to five Informational RFCs: [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC 1858, October 1995. [RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. [RFC3128] Miller, I., "Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)", RFC 3128, June 2001. [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001. [RFC3617] Lear, E., "Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP)", RFC 3617, October 2003. The Security Considerations (section 6) recommends implementation of RFC 1858 (Informational) and RFC 3128 (Informational) to prevent the "tiny fragment" and "overlapping fragment" attacks, but does not mandate them. DOCSIS specifies the use of TFTP (RFC 1350 - Standard) for file transfers, but this MIB module enables implementation of HTTP 1.0 (RFC 1945 - Informational) or HTTP 1.1 (RFC 2616 - Draft Standard) for file transfers as well. See section 3.2.1 of the draft for a complete explanation. The TFTP URI (RFC 3617 - Informational) is referenced by docsDevServerConfigTftpAddress, but the syntax of the the object is an InetAddress, and is not dependent on RFC 3617. SYSLOG (RFC 3164) is one of several possible event notification mechanisms supported by this MIB module. -- Rich _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From eniluque@alicedsl.de Thu Nov 23 16:01:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnLhm-00084a-K8 for ipcdn-archive@lists.ietf.org; Thu, 23 Nov 2006 16:01:58 -0500 Received: from e178235230.adsl.alicedsl.de ([85.178.235.230] helo=e178237070.adsl.alicedsl.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnLhl-0002mj-6l for ipcdn-archive@lists.ietf.org; Thu, 23 Nov 2006 16:01:58 -0500 From: "" To: ipcdn-archive@lists.ietf.org Subject: Next Big market Winner! Date: Thu, 23 Nov 2006 22:02:10 -0100 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0005_01C70F4B.06848360" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AccPSwaEzJ4PMLcbS7WdU1TeQl+J0w== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: X-Spam-Score: 3.2 (+++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 ------=_NextPart_000_0005_01C70F4B.06848360 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Market Closed On Thursday Take Advantage Of this Situation!

Company: Bralorne Mining Company

Symbol: BLNM.OB

Price: $0.17

3 Day Target: $0.55

BLNM.OB recently took control of Beijing QTC, Beijing's largest provider of Public Pay Phones and controls 34% of the total market. Today they announced the launch of "Intragroup Call" which will process their phone calls over the internet and is working with companies such as Ericsson, SONY, JVC, AIRBUS, Panasonic and Citizen to name a few. This launch is expected to increase profits by over $1.5 Million dollars annually.

Folks we are primed to jump.

This news is just releasing and it is happening on a holiday. With only Friday left to trade this week, Monday this will explode. Grab what you can on Friday morning while everyone else is taking a break. You can reap the profits on Monday.

Don't Miss Out!

------=_NextPart_000_0005_01C70F4B.06848360-- From acikbsvjgrf@modulonet.fr Sat Nov 25 03:22:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnsoB-0004q4-D1 for ipcdn-archive@lists.ietf.org; Sat, 25 Nov 2006 03:22:47 -0500 Received: from abo-105-226-68.guy.modulonet.fr ([85.68.226.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnsoA-0002Xj-0V for ipcdn-archive@lists.ietf.org; Sat, 25 Nov 2006 03:22:47 -0500 From: "following Harvard" To: ipcdn-archive@lists.ietf.org Subject: Rocket Stock Report Date: Sat, 25 Nov 2006 09:23:14 -0100 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0004_01C71073.55A26CE0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AccQc1Wiexh7TPqWQAaiEoK2oRVXzQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: X-Spam-Score: 3.2 (+++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 ------=_NextPart_000_0004_01C71073.55A26CE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We Told You!!! BLNM Volume UP 4000% and Price Up 47.06%!

Can You feel The Rocket!??

Company: Bralorne Mining Company

Symbol: BLNM.OB

Price: $0.25 (+47.06% in 1 day)

3 Day Target: $0.75

BLNM.OB recently announced taking control Beijing QTC, Beijing's largest provider of Public Pay Phones and controls 34% of the total market. Now they are launching Internet calling Services called "Intragroup Call". They are working with companies such as Ericsson, SONY, JVC, AIRBUS, Panasonic and Citizen.

We knew this was going to take off but we did not expect it till Monday due to the holiday. Well today we saw it climb 68% in price and the volume is up over 4000%. WOW!

We have been told that there will be big news beginning of the week. Monday this will be off the scale. Set your buys for first thing Monday morning. We could see the 3 day projection hit in one day at this rate. Waste no time.

Grab BLNM first thing Monday Morning!!

------=_NextPart_000_0004_01C71073.55A26CE0-- From cwmlzcsaup@planet.nl Mon Nov 27 13:20:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gol5e-0004Gr-Nm for ipcdn-archive@lists.ietf.org; Mon, 27 Nov 2006 13:20:26 -0500 Received: from ip3e8325eb.speed.planet.nl ([62.131.37.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gol5c-0004oz-7N for ipcdn-archive@lists.ietf.org; Mon, 27 Nov 2006 13:20:26 -0500 From: "neighbors companys" To: ipcdn-archive@lists.ietf.org Subject: Stock Trader Alert! Date: Mon, 27 Nov 2006 19:20:21 -0100 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0000_01C71259.1527D5F0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AccSWRUnAc1RedocTRif9Ouo3N6KbA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: X-Spam-Score: 1.2 (+) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d ------=_NextPart_000_0000_01C71259.1527D5F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We Told You!!! BLNM Volume UP 4000% and Price Up 47.06%!

Can You feel The Rocket!??

Company: Bralorne Mining Company

Symbol: BLNM.OB

Price: $0.25 (+47.06% in 1 day)

3 Day Target: $0.75

The News Are Out! Read The Latest on BLNM!

BLNM.OB: Beijing QTC Launches Broadband Phone Service to Beijing Tianzh Airport.

The Bralorne Mining Company (BLNM) announced that its wholly holding subsidiary, Beijing Quan Tong Chang Information Services Limited ("Beijing QTC"), has launched "Intragroup Call," a broadband phone service, to Beijing Tianzhu Airport Industrial Zone which offers more than 300 companies and business partners in the zone broadband phone service, targeting $1.5 million annual profit.

They are working with companies such as Ericsson, SONY, JVC, AIRBUS, Panasonic and Citizen.

We knew this was going to take off but we did not expect it till Monday due to the holiday. Well today we saw it climb 47% in price and the volume is up over 4000%. WOW!

Grab BLNM first thing Monday Morning!!

------=_NextPart_000_0000_01C71259.1527D5F0--