From akstcarbourmnsdgs@arbour.com Mon Nov 06 07:03:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh3Cb-0001ex-NI for pana-archive@lists.ietf.org; Mon, 06 Nov 2006 07:03:45 -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 1Gh34w-0006BY-FC for pana-archive@lists.ietf.org; Mon, 06 Nov 2006 06:55:50 -0500 Received: from bxf202.neoplus.adsl.tpnet.pl ([83.29.255.202] helo=adrian-svxkvwey) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gh34c-0007CL-0q for pana-archive@lists.ietf.org; Mon, 06 Nov 2006 06:55:50 -0500 Received: from 205.151.16.15 (HELO relay.infoteck.qc.ca) by lists.ietf.org with esmtp (X2XZWZFV BYAG3) id 4TBYM9-R6O9K6-O6 for pana-archive@lists.ietf.org; Mon, 6 Dec 2006 11:55:36 -0060 Message-ID: <01c7019a$7872f6a0$6c822ecf@akstcarbourmnsdgs> From: "Gregory Foster" To: Subject: Howdy Date: Mon, 6 Dec 2006 11:55:36 -0060 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C701A2.DA375EA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Spam-Score: 3.9 (+++) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C701A2.DA375EA0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C701A2.DA375EA0" ------=_NextPart_001_0010_01C701A2.DA375EA0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable "you need not distress yourself. the moral will be perfectly fair. lady=20= catherine's unjustifiableapparently be to any one, that the good opinion=20= which all the neighbourhood had of him should then be"no, my dear, i=20= think not. i have great hopes of finding him quite the reverse. there is=20= a mixtureconfirmation of it; if, indeed, such a report is in=20= existence."deceive you, but my spirits might often lead me wrong. how=20= you must have hated me after that"i have heard, indeed, that she is=20= uncommonly improved within this year or two. when i last sawelizabeth=20= looked surprised. the gentleman experienced some change of feeling; he=20= drew back"elizabeth, you are not serious now."be perceived in her at=20= all, and was really persuaded that she talked as much as ever. but her=20= mind wasand elizabeth continued her walk alone, crossing field after=20= field at a quick pace, jumping over stilesadvise you by all means to=20= refuse him."aware that the interest of one thousand pounds would be a=20= very insufficient support therein. i ratherelizabeth had now but little=20= time for conversation with her sister; for while he was present,=20= janeeager to satisfy. after joining in general lamentations over the=20= dreadful sequel of this event, which"we have not determined how far it=20= shall carry us," said mrs. gardiner, "but, perhaps, to the"i did not=20= think you would; and that being the case, i cannot consider your=20= situation with muchanything rather than marry without affection. are you=20= quite sure that you feel what you ought to do?"couple in the world. but=20= are you pleased, jane? shall you like to have such a brother?"been=20= fidgety from alarm and vexation. to know that her daughter would be=20= married was enough. shebearing with, her husband, and to acknowledge=20= that it was all done very well. she had also to"that is very strange.=20= but i suppose you had no opportunity. your mother should have taken=20= you"and may i ask-" said elizabeth; "but the terms, i suppose, must be=20= complied with."T> ------=_NextPart_001_0010_01C701A2.DA375EA0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
3D""
"you=20= need not distress yourself. the moral will be perfectly fair. lady=20= catherine's unjustifiable
apparently be to any one, that the good=20= opinion which all the neighbourhood had of him should then be
"no, my=20= dear, i think not. i have great hopes of finding him quite the reverse.=20= there is a mixture
confirmation of it; if, indeed, such a report is=20= in existence."
deceive you, but my spirits might often lead me wrong.=20= how you must have hated me after that
"i have heard, indeed, that she=20= is uncommonly improved within this year or two. when i last=20= saw
elizabeth looked surprised. the gentleman experienced some change=20= of feeling; he drew back
"elizabeth, you are not serious now."
be=20= perceived in her at all, and was really persuaded that she talked as=20= much as ever. but her mind was
and elizabeth continued her walk=20= alone, crossing field after field at a quick pace, jumping over=20= stiles
advise you by all means to refuse him."
aware that the=20= interest of one thousand pounds would be a very insufficient support=20= therein. i rather
elizabeth had now but little time for conversation=20= with her sister; for while he was present, jane
eager to satisfy.=20= after joining in general lamentations over the dreadful sequel of this=20= event, which
"we have not determined how far it shall carry us," said=20= mrs. gardiner, "but, perhaps, to the
"i did not think you would; and=20= that being the case, i cannot consider your situation with=20= much
anything rather than marry without affection. are you quite sure=20= that you feel what you ought to do?"
couple in the world. but are you=20= pleased, jane? shall you like to have such a brother?"
been fidgety=20= from alarm and vexation. to know that her daughter would be married was=20= enough. she
bearing with, her husband, and to acknowledge that it was=20= all done very well. she had also to
"that is very strange. but i=20= suppose you had no opportunity. your mother should have taken=20= you
"and may i ask-" said elizabeth; "but the terms, i suppose, must=20= be complied with."
 ------=_NextPart_001_0010_01C701A2.DA375EA0-- ------=_NextPart_000_000F_01C701A2.DA375EA0 Content-Type: image/gif; name="orxqssj.gif" Content-ID: <006901c7019a$7872f6a0$6c822ecf@67FD305> Content-Transfer-Encoding: base64 R0lGODdhAgABAKIAAP////8AAMyZAJkAAACZAAAA/wAAAAAAACwAAAAAAgABAAADAjiTADs= ------=_NextPart_000_000F_01C701A2.DA375EA0-- From pana-bounces@ietf.org Mon Nov 06 12:09:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh7xO-0003oI-1J; Mon, 06 Nov 2006 12:08:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh7xM-0003mQ-Kj for pana@ietf.org; Mon, 06 Nov 2006 12:08:20 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh7xG-0004VE-Vv for pana@ietf.org; Mon, 06 Nov 2006 12:08:20 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 06 Nov 2006 18:08:14 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAEb6TkWQ/uCKY2dsb2JhbACMQBQPKg X-IronPort-AV: i="4.09,392,1157320800"; d="scan'208"; a="117512983:sNHT40731244" 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.20060308/8.12.11) with ESMTP id kA6H8El2016659 for ; Mon, 6 Nov 2006 18:08:14 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA6H8D4Z014037 for ; Mon, 6 Nov 2006 18:08:13 +0100 (MET) 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); Mon, 6 Nov 2006 18:08:13 +0100 Received: from [130.129.67.118] ([10.21.80.104]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 09:08:13 -0800 Message-ID: <454F6BFC.3000509@cisco.com> Date: Mon, 06 Nov 2006 09:08:12 -0800 From: Mark Townsley User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: pana@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Nov 2006 17:08:13.0295 (UTC) FILETIME=[249FBFF0:01C701C6] DKIM-Signature: a=rsa-sha1; q=dns; l=3895; t=1162832894; x=1163696894; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:Mark=20Townsley=20 |Subject:Language=20tag=20review; X=v=3Dcisco.com=3B=20h=3DhNyrLLg7/ucsHPqZe/9o7H4KOuU=3D; b=vvyaoh608RoUXNxqsIu7MJ3Ee6yQIz1kRYKvWZy76LqFP8kB3LErGkuhk0lKhW3+CaWkvN00 CXblkKPUzNEmzsqr7Tx7saz6hyv20zJlbeyknmZGzf5aLS3DMgWlLQOJ; Authentication-Results: ams-dkim-1; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Subject: [Pana] Language tag review X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org -------- Original Message -------- Subject: Re: [Fwd: Re: Looking for a Language tag expert] Date: Fri, 06 Oct 2006 18:19:12 +0900 From: Martin Duerst To: Mark Townsley , ltru-chairs@tools.ietf.org CC: Ted Hardie References: <45253A9F.6050208@cisco.com> Hello Mark, Please see below. This review is made having no idea what your draft is about, but I hope it helps anyway. At 02:02 06/10/06, Mark Townsley wrote: > >Could one of you review this bit of text? > >Thank you, > >- Mark > >-------- Original Message -------- >Subject: Re: Looking for a Language tag expert >Date: Thu, 5 Oct 2006 09:54:35 -0700 >From: Ted Hardie >To: Mark Townsley , IESG >References: <4524FBB5.4080001@cisco.com> > > > >At 2:33 PM +0200 10/5/06, Mark Townsley wrote: >>I would like a language tag expert to review the following text from draft-ietf-pana-pana-12.txt >> >>If there is someone here that can do this, great, if not, please forward on or tell me whom to forward it to. >> >>Thanks. >> >>8.11. Notification AVP >> >> The Notification AVP (AVP Code 11) is optionally used to convey a >> displayable message sent by either the PaC or the PAA. It can be >> included in any message, whether it is a request or answer. In case >> a notification needs to be sent but there is no outgoing PANA message >> to deliver this AVP, a PANA-Update-Request that only carries a >> Notification AVP SHOULD be generated. >> >> The 'M' bit in the AVP header of this AVP MUST NOT be set. >> >> Receipt this AVP does not change PANA state. >> >> AVP data is of type OctetString and it contains the following fields >> in the listed order: >> >> Language Tag Length >> >> This field contains the length of the Language Tag in octets. The >> length of this field is 2 octets. Are these octets hex or dec? If it's hex, the length is way enough of course. If it's dec, we still have 99 as a max, which is way above the various limits we have in RFC 4646. >> Language Tag >> >> This field contains the language tag defined in [I-D.ietf-ltru- >> registry] to indicate the language used for Displayable String. >> The length of this data is determined by the Language Tag Length >> field. Please replace [I-D.ietf-ltru-registry] with RFC 4646, or even better, BCP 47 (because we are already working on an update to RFC 4646, to add much more language codes). >> Displayable String >> >> This field contains UTF-8 encoded ISO 10646 characters [RFC2279] >> using the language indicated by the Language Tag. The length of >> this data is determined by the AVP Length field and the Language >> Tag Length field. This data MUST NOT be null terminated. Is my understanding correct that the length of this is the AVP length minus the language tag length minus the 2 octets of the language tag length field minus possibly some other stuff included in the AVP length? If you are confident that the average reader of your draft will figure this out correctly, then it's fine with me. I assume that how the 'server' side of the protocol gets an idea of what languages to send is also dealt with in the protocol. Sending every language available isn't scalable, there are just too many language. RFC 4647 (also part of BCP 47) may be relevant for defining how the server matches language ranges in requests or commands to the languges it returns. Regards, Martin. >Martin Duerst, co-chair of ltru would be an appropriate reviewer. > Ted > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From akstcamerigroupcorpmnsdgs@amerigroupcorp.com Tue Nov 07 03:24:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhMG6-00062O-Ul for pana-archive@lists.ietf.org; Tue, 07 Nov 2006 03:24:38 -0500 Received: from [59.188.226.154] (helo=hair-d9kbyb1zr2) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhMG2-0007YG-B2 for pana-archive@lists.ietf.org; Tue, 07 Nov 2006 03:24:38 -0500 Received: from 216.54.32.129 (HELO mail1.amerigroupcorp.com) by lists.ietf.org with esmtp (I1SJ0U3C6MHE 7DT0I) id NMUNXN-YLKJ1P-FL for pana-archive@lists.ietf.org; Tue, 7 Dec 2006 08:24:36 -0480 Message-ID: <01c70246$2930aa90$6c822ecf@akstcamerigroupcorpmnsdgs> From: "Shaun Stein" To: Subject: Feel strong Date: Tue, 7 Dec 2006 08:24:36 -0480 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Spam-Score: 1.4 (+) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 RREF Pricce Settles And On The Rise! Time To Get In Is Now! Red Reef Labs For New Manufacdturing and Distribution Contract In China! Compasny red Reef Laboratoories Inc. SYMB ol: R REF Price: $0.352 Recommendation: ST RO NG B UY RREF has been climbing up and down the pricye ladder due to so many changes in the marekt and this companlies dynamic directions and news relesaes. The pricae has settled and Volusme is rising as investoirs are jumping in before the climb. Just look at some of the releases over the last 4 weeks. This one will climb hard. They have news cominbg out end of week and it is expected to push this up 300%. READ up on the news. LOOK at the amazing potential and. GET into RREF Tue, November 7, 2006 before the climb continues. I hope it was a helper. I'll email you later this week. Shaun Stein. "because honour, decorum, prudence, nay, interest, forbid it. yes, miss bennet, interest; for do "oh! certainly," said elizabeth, though burning with curiosity; "we will ask you no que as he quitted the room, elizabeth felt how improbable it was that they should ever see each other elizabeth said as little to either as civility would allow, and sat down again to her work, with an "you may well warn me against such an evil. human nature is so prone to fall into it! no, lizzy, "had you then persuaded yourself that i should?" did not, in taking place, bring all the satisfaction she had promised herself. it was consequently dreaded; for though he was not always looking at her mother, she was convinced that his attention was as soon as they entered, bingley looked at her so expressively, and shook hands with such elizabeth turned away to hide a smile. and that there was scarcely an eye which did not watch his behaviour when he first came into the anything before the elopement took place? they must have seen them together for ever." always speaking, and looking, and thinking for your approbation alone. i roused, and interested you, "it is only evident that miss bingley does not mean that he should ." "my father is gone to london, and jane has written to beg my uncle's immediate assistance; and From pana-bounces@ietf.org Fri Nov 10 02:32:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiQrQ-0004SC-J2; Fri, 10 Nov 2006 02:31:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiQrP-0004S7-QM for pana@ietf.org; Fri, 10 Nov 2006 02:31:35 -0500 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiQrJ-0007tY-9N for pana@ietf.org; Fri, 10 Nov 2006 02:31:35 -0500 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id kAA7UWwJ098387; Fri, 10 Nov 2006 02:30:35 -0500 (EST) (envelope-from yohba@tari.toshiba.com) Date: Fri, 10 Nov 2006 02:30:30 -0500 To: Mark Townsley Subject: Re: [Pana] Language tag review Message-ID: <20061110073030.GE6266@steelhead> References: <454F6BFC.3000509@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <454F6BFC.3000509@cisco.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 127 X-Spam-Score: -2.4 (--) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: pana@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org I am concerned on the last part of review comment on matching language range. I strongly believe that adding matching language range functionality is too much for a network access authentication protocol. I am inclined to remove Notification AVP from PANA specification. This could be another simplification to PANA. Yoshihiro Ohba On Mon, Nov 06, 2006 at 09:08:12AM -0800, Mark Townsley wrote: > > > -------- Original Message -------- > Subject: Re: [Fwd: Re: Looking for a Language tag expert] > Date: Fri, 06 Oct 2006 18:19:12 +0900 > From: Martin Duerst > To: Mark Townsley , ltru-chairs@tools.ietf.org > CC: Ted Hardie > References: <45253A9F.6050208@cisco.com> > > > > Hello Mark, > > Please see below. This review is made having no idea > what your draft is about, but I hope it helps anyway. > > At 02:02 06/10/06, Mark Townsley wrote: > > > >Could one of you review this bit of text? > > > >Thank you, > > > >- Mark > > > >-------- Original Message -------- > >Subject: Re: Looking for a Language tag expert > >Date: Thu, 5 Oct 2006 09:54:35 -0700 > >From: Ted Hardie > >To: Mark Townsley , IESG > >References: <4524FBB5.4080001@cisco.com> > > > > > > > >At 2:33 PM +0200 10/5/06, Mark Townsley wrote: > >>I would like a language tag expert to review the following text from > >>draft-ietf-pana-pana-12.txt > >> > >>If there is someone here that can do this, great, if not, please forward > >>on or tell me whom to forward it to. > >> > >>Thanks. > >> > >>8.11. Notification AVP > >> > >> The Notification AVP (AVP Code 11) is optionally used to convey a > >> displayable message sent by either the PaC or the PAA. It can be > >> included in any message, whether it is a request or answer. In case > >> a notification needs to be sent but there is no outgoing PANA message > >> to deliver this AVP, a PANA-Update-Request that only carries a > >> Notification AVP SHOULD be generated. > >> > >> The 'M' bit in the AVP header of this AVP MUST NOT be set. > >> > >> Receipt this AVP does not change PANA state. > >> > >> AVP data is of type OctetString and it contains the following fields > >> in the listed order: > >> > >> Language Tag Length > >> > >> This field contains the length of the Language Tag in octets. The > >> length of this field is 2 octets. > > Are these octets hex or dec? If it's hex, the length is way enough > of course. If it's dec, we still have 99 as a max, which is way > above the various limits we have in RFC 4646. > > >> Language Tag > >> > >> This field contains the language tag defined in [I-D.ietf-ltru- > >> registry] to indicate the language used for Displayable String. > >> The length of this data is determined by the Language Tag Length > >> field. > > Please replace [I-D.ietf-ltru-registry] with RFC 4646, or even > better, BCP 47 (because we are already working on an update to > RFC 4646, to add much more language codes). > > >> Displayable String > >> > >> This field contains UTF-8 encoded ISO 10646 characters [RFC2279] > >> using the language indicated by the Language Tag. The length of > >> this data is determined by the AVP Length field and the Language > >> Tag Length field. This data MUST NOT be null terminated. > > Is my understanding correct that the length of this is the AVP length > minus the language tag length minus the 2 octets of the language tag > length field minus possibly some other stuff included in the AVP length? > If you are confident that the average reader of your draft will > figure this out correctly, then it's fine with me. > > I assume that how the 'server' side of the protocol gets an idea > of what languages to send is also dealt with in the protocol. > Sending every language available isn't scalable, there are just > too many language. RFC 4647 (also part of BCP 47) may be relevant > for defining how the server matches language ranges in requests > or commands to the languges it returns. > > > Regards, Martin. > > >Martin Duerst, co-chair of ltru would be an appropriate reviewer. > > Ted > > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Mon Nov 13 12:00:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjf9n-00065w-VV; Mon, 13 Nov 2006 11:59:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjf9n-00065r-16 for pana@ietf.org; Mon, 13 Nov 2006 11:59:39 -0500 Received: from mout.perfora.net ([217.160.230.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjf9j-0006fw-Lr for pana@ietf.org; Mon, 13 Nov 2006 11:59:39 -0500 Received: from [85.99.180.232] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrelayus0) with ESMTP (Nemesis), id 0MKoyl-1Gjf9e1DXD-0003yL; Mon, 13 Nov 2006 11:59:35 -0500 From: "Alper Yegin" To: "'Yoshihiro Ohba'" , "'Mark Townsley'" Subject: RE: [Pana] Language tag review Date: Mon, 13 Nov 2006 18:59:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20061110073030.GE6266@steelhead> Thread-Index: AccEmmBFpq3/lkyTTfS5jCCo6J+rPQCqnalA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Message-ID: <0MKoyl-1Gjf9e1DXD-0003yL@mrelay.perfora.net> X-Provags-ID: perfora.net abuse@perfora.net login:abf7a4bb310ea4dfc9b6841113e2970f X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: pana@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org I'm wondering what it takes to do range matching. Are there any examples? Alper > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Friday, November 10, 2006 9:31 AM > To: Mark Townsley > Cc: pana@ietf.org > Subject: Re: [Pana] Language tag review > > I am concerned on the last part of review comment on matching language > range. I strongly believe that adding matching language range > functionality is too much for a network access authentication > protocol. > > I am inclined to remove Notification AVP from PANA specification. > This could be another simplification to PANA. > > Yoshihiro Ohba > > On Mon, Nov 06, 2006 at 09:08:12AM -0800, Mark Townsley wrote: > > > > > > -------- Original Message -------- > > Subject: Re: [Fwd: Re: Looking for a Language tag expert] > > Date: Fri, 06 Oct 2006 18:19:12 +0900 > > From: Martin Duerst > > To: Mark Townsley , ltru-chairs@tools.ietf.org > > CC: Ted Hardie > > References: <45253A9F.6050208@cisco.com> > > > > > > > > Hello Mark, > > > > Please see below. This review is made having no idea > > what your draft is about, but I hope it helps anyway. > > > > At 02:02 06/10/06, Mark Townsley wrote: > > > > > >Could one of you review this bit of text? > > > > > >Thank you, > > > > > >- Mark > > > > > >-------- Original Message -------- > > >Subject: Re: Looking for a Language tag expert > > >Date: Thu, 5 Oct 2006 09:54:35 -0700 > > >From: Ted Hardie > > >To: Mark Townsley , IESG > > >References: <4524FBB5.4080001@cisco.com> > > > > > > > > > > > >At 2:33 PM +0200 10/5/06, Mark Townsley wrote: > > >>I would like a language tag expert to review the following text from > > >>draft-ietf-pana-pana-12.txt > > >> > > >>If there is someone here that can do this, great, if not, please > forward > > >>on or tell me whom to forward it to. > > >> > > >>Thanks. > > >> > > >>8.11. Notification AVP > > >> > > >> The Notification AVP (AVP Code 11) is optionally used to convey a > > >> displayable message sent by either the PaC or the PAA. It can be > > >> included in any message, whether it is a request or answer. In case > > >> a notification needs to be sent but there is no outgoing PANA message > > >> to deliver this AVP, a PANA-Update-Request that only carries a > > >> Notification AVP SHOULD be generated. > > >> > > >> The 'M' bit in the AVP header of this AVP MUST NOT be set. > > >> > > >> Receipt this AVP does not change PANA state. > > >> > > >> AVP data is of type OctetString and it contains the following fields > > >> in the listed order: > > >> > > >> Language Tag Length > > >> > > >> This field contains the length of the Language Tag in octets. The > > >> length of this field is 2 octets. > > > > Are these octets hex or dec? If it's hex, the length is way enough > > of course. If it's dec, we still have 99 as a max, which is way > > above the various limits we have in RFC 4646. > > > > >> Language Tag > > >> > > >> This field contains the language tag defined in [I-D.ietf-ltru- > > >> registry] to indicate the language used for Displayable String. > > >> The length of this data is determined by the Language Tag Length > > >> field. > > > > Please replace [I-D.ietf-ltru-registry] with RFC 4646, or even > > better, BCP 47 (because we are already working on an update to > > RFC 4646, to add much more language codes). > > > > >> Displayable String > > >> > > >> This field contains UTF-8 encoded ISO 10646 characters [RFC2279] > > >> using the language indicated by the Language Tag. The length of > > >> this data is determined by the AVP Length field and the Language > > >> Tag Length field. This data MUST NOT be null terminated. > > > > Is my understanding correct that the length of this is the AVP length > > minus the language tag length minus the 2 octets of the language tag > > length field minus possibly some other stuff included in the AVP length? > > If you are confident that the average reader of your draft will > > figure this out correctly, then it's fine with me. > > > > I assume that how the 'server' side of the protocol gets an idea > > of what languages to send is also dealt with in the protocol. > > Sending every language available isn't scalable, there are just > > too many language. RFC 4647 (also part of BCP 47) may be relevant > > for defining how the server matches language ranges in requests > > or commands to the languges it returns. > > > > > > Regards, Martin. > > > > >Martin Duerst, co-chair of ltru would be an appropriate reviewer. > > > Ted > > > > > > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Tue Nov 14 19:54:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk91s-0001O5-OE; Tue, 14 Nov 2006 19:53:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk91r-0001NU-1B for pana@ietf.org; Tue, 14 Nov 2006 19:53:27 -0500 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk91Z-00078j-PB for pana@ietf.org; Tue, 14 Nov 2006 19:53:11 -0500 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id kAF0qLGH018796; Tue, 14 Nov 2006 19:52:21 -0500 (EST) (envelope-from yohba@tari.toshiba.com) Date: Tue, 14 Nov 2006 19:52:25 -0500 To: Alper Yegin Subject: Re: [Pana] Language tag review Message-ID: <20061115005224.GP14625@steelhead> References: <20061110073030.GE6266@steelhead> <0MKoyl-1Gjf9e1DXD-0003yL@mrelay.perfora.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <0MKoyl-1Gjf9e1DXD-0003yL@mrelay.perfora.net> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 209 X-Spam-Score: -2.4 (--) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Cc: 'Mark Townsley' , 'Yoshihiro Ohba' , pana@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org OK. Let me give several examples based on my reading of RFC 4647. Please allow me to give very rough explanation to be concise. Language range has a format that is very similar to language tag, but language range is used only as input parameter for language matching. It is assumed that matching is performed againt a pre-configured set of language tags which are not shown in the examples. There are two basic methods for matching, i.e., filtering and lookup. Filtering --------- This is used for matching language ranges to language tags that least matches the language ranges. Example 1: - Input: en - Output: en-US, en-UK Example 2: - Input: ja, en - Output: ja-JP, en-US, en-UK Example 3: - Input: * - Output: ja-JP, en-US, en-UK, de-DE Example 4: - Input: de-*-de - Output: de-DE, de-Latn-DE, de-Latf-DE, de-DE-x-goethe, de-Latn-DE-1996, de-Deva-DE Lookup ------ This is used for matching language ranges to a single language tag that best matches with the language ranges. Example 5: - Input: zh-Hant-CN-x-private1-private2 - Ouput: zh-Hant-CN Example 6: - Input: zh-Hant-CN-x-private1-private2, zh-Hant-CN-x - Ouput: zh-Hant-CN-x-private1 Regards, Yoshihiro Ohba On Mon, Nov 13, 2006 at 06:59:27PM +0200, Alper Yegin wrote: > I'm wondering what it takes to do range matching. Are there any examples? > > Alper > > > > -----Original Message----- > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > Sent: Friday, November 10, 2006 9:31 AM > > To: Mark Townsley > > Cc: pana@ietf.org > > Subject: Re: [Pana] Language tag review > > > > I am concerned on the last part of review comment on matching language > > range. I strongly believe that adding matching language range > > functionality is too much for a network access authentication > > protocol. > > > > I am inclined to remove Notification AVP from PANA specification. > > This could be another simplification to PANA. > > > > Yoshihiro Ohba > > > > On Mon, Nov 06, 2006 at 09:08:12AM -0800, Mark Townsley wrote: > > > > > > > > > -------- Original Message -------- > > > Subject: Re: [Fwd: Re: Looking for a Language tag expert] > > > Date: Fri, 06 Oct 2006 18:19:12 +0900 > > > From: Martin Duerst > > > To: Mark Townsley , > ltru-chairs@tools.ietf.org > > > CC: Ted Hardie > > > References: <45253A9F.6050208@cisco.com> > > > > > > > > > > > > Hello Mark, > > > > > > Please see below. This review is made having no idea > > > what your draft is about, but I hope it helps anyway. > > > > > > At 02:02 06/10/06, Mark Townsley wrote: > > > > > > > >Could one of you review this bit of text? > > > > > > > >Thank you, > > > > > > > >- Mark > > > > > > > >-------- Original Message -------- > > > >Subject: Re: Looking for a Language tag expert > > > >Date: Thu, 5 Oct 2006 09:54:35 -0700 > > > >From: Ted Hardie > > > >To: Mark Townsley , IESG > > > >References: <4524FBB5.4080001@cisco.com> > > > > > > > > > > > > > > > >At 2:33 PM +0200 10/5/06, Mark Townsley wrote: > > > >>I would like a language tag expert to review the following text from > > > >>draft-ietf-pana-pana-12.txt > > > >> > > > >>If there is someone here that can do this, great, if not, please > > forward > > > >>on or tell me whom to forward it to. > > > >> > > > >>Thanks. > > > >> > > > >>8.11. Notification AVP > > > >> > > > >> The Notification AVP (AVP Code 11) is optionally used to convey a > > > >> displayable message sent by either the PaC or the PAA. It can be > > > >> included in any message, whether it is a request or answer. In case > > > >> a notification needs to be sent but there is no outgoing PANA message > > > >> to deliver this AVP, a PANA-Update-Request that only carries a > > > >> Notification AVP SHOULD be generated. > > > >> > > > >> The 'M' bit in the AVP header of this AVP MUST NOT be set. > > > >> > > > >> Receipt this AVP does not change PANA state. > > > >> > > > >> AVP data is of type OctetString and it contains the following fields > > > >> in the listed order: > > > >> > > > >> Language Tag Length > > > >> > > > >> This field contains the length of the Language Tag in octets. The > > > >> length of this field is 2 octets. > > > > > > Are these octets hex or dec? If it's hex, the length is way enough > > > of course. If it's dec, we still have 99 as a max, which is way > > > above the various limits we have in RFC 4646. > > > > > > >> Language Tag > > > >> > > > >> This field contains the language tag defined in [I-D.ietf-ltru- > > > >> registry] to indicate the language used for Displayable String. > > > >> The length of this data is determined by the Language Tag Length > > > >> field. > > > > > > Please replace [I-D.ietf-ltru-registry] with RFC 4646, or even > > > better, BCP 47 (because we are already working on an update to > > > RFC 4646, to add much more language codes). > > > > > > >> Displayable String > > > >> > > > >> This field contains UTF-8 encoded ISO 10646 characters [RFC2279] > > > >> using the language indicated by the Language Tag. The length of > > > >> this data is determined by the AVP Length field and the Language > > > >> Tag Length field. This data MUST NOT be null terminated. > > > > > > Is my understanding correct that the length of this is the AVP length > > > minus the language tag length minus the 2 octets of the language tag > > > length field minus possibly some other stuff included in the AVP length? > > > If you are confident that the average reader of your draft will > > > figure this out correctly, then it's fine with me. > > > > > > I assume that how the 'server' side of the protocol gets an idea > > > of what languages to send is also dealt with in the protocol. > > > Sending every language available isn't scalable, there are just > > > too many language. RFC 4647 (also part of BCP 47) may be relevant > > > for defining how the server matches language ranges in requests > > > or commands to the languges it returns. > > > > > > > > > Regards, Martin. > > > > > > >Martin Duerst, co-chair of ltru would be an appropriate reviewer. > > > > Ted > > > > > > > > > > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > > > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > > > > > > > > _______________________________________________ > > > Pana mailing list > > > Pana@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Mon Nov 20 19:27:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmJSo-0006Mv-Kk; Mon, 20 Nov 2006 19:26:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmJSn-0006L0-Fp for pana@ietf.org; Mon, 20 Nov 2006 19:26:13 -0500 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmJSh-0004HI-4I for pana@ietf.org; Mon, 20 Nov 2006 19:26:13 -0500 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id kAL0PM7m000360 for ; Mon, 20 Nov 2006 19:25:23 -0500 (EST) (envelope-from yohba@tari.toshiba.com) Date: Sun, 19 Nov 2006 03:39:03 -0500 To: pana@ietf.org Message-ID: <20061119083903.GC31177@steelhead> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 15 X-Spam-Score: -2.1 (--) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Pana] Preliminary pana-pana draft (13a) X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org is available at: http://www.panasec.org/docs/editing/pana-spec.html (Now we get 17 pages reduction.) Please do sanity check to make sure that all resolutions discussed in IETF67 and over mailing list are reflected appropriately. Diff from revision 12 is also available. As soon as sanity check is done, I will submit a new revision (13) which is to be used for IETF last call. Regards, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Tue Nov 21 10:31:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmXZV-000845-JO; Tue, 21 Nov 2006 10:30:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmXZS-00083i-VI for pana@ietf.org; Tue, 21 Nov 2006 10:30:02 -0500 Received: from mout.perfora.net ([217.160.230.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmXZQ-0006A9-NV for pana@ietf.org; Tue, 21 Nov 2006 10:30:02 -0500 Received: from [85.102.133.158] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrelayus1) with ESMTP (Nemesis), id 0MKp2t-1GmXZL49QR-0003s9; Tue, 21 Nov 2006 10:29:59 -0500 From: "Alper Yegin" To: "'Yoshihiro Ohba'" , Subject: RE: [Pana] Preliminary pana-pana draft (13a) Date: Tue, 21 Nov 2006 17:29:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccNA8viG80KCD8rRnqXTgeVPuq5rQAefS8A In-Reply-To: <20061119083903.GC31177@steelhead> Message-ID: <0MKp2t-1GmXZL49QR-0003s9@mrelay.perfora.net> X-Provags-ID: perfora.net abuse@perfora.net login:abf7a4bb310ea4dfc9b6841113e2970f X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Thank you Yoshi. Let's set a timer. PANA WG members: Please review and register your feedback by the end of Nov 28 (one week). Alper > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Sunday, November 19, 2006 10:39 AM > To: pana@ietf.org > Subject: [Pana] Preliminary pana-pana draft (13a) > > is available at: > > http://www.panasec.org/docs/editing/pana-spec.html > > (Now we get 17 pages reduction.) > > Please do sanity check to make sure that all resolutions discussed in > IETF67 and over mailing list are reflected appropriately. Diff from > revision 12 is also available. > > As soon as sanity check is done, I will submit a new revision (13) > which is to be used for IETF last call. > > Regards, > Yoshihiro Ohba > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From sgxdrxxva@rima-tde.net Sat Nov 25 07:05:27 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnwHf-00026m-CQ for pana-archive@lists.ietf.org; Sat, 25 Nov 2006 07:05:27 -0500 Received: from 248.red-83-33-155.dynamicip.rima-tde.net ([83.33.155.248]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GnwHd-00057Q-L1 for pana-archive@lists.ietf.org; Sat, 25 Nov 2006 07:05:27 -0500 From: "mascot." To: pana-archive@lists.ietf.org Subject: Wall Street Alert! Date: Sat, 25 Nov 2006 13:05:20 -0100 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0001_01C71092.5C403590" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AccQklxAQ1n8P0GjQHSrICchqVHZaA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <1BE2BB7F2939CEB.E0FAFAA3BF@rima-tde.net> X-Spam-Score: 3.9 (+++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 ------=_NextPart_000_0001_01C71092.5C403590 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_0001_01C71092.5C403590-- From pana-bounces@ietf.org Mon Nov 27 19:04:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoqST-0001kQ-Sa; Mon, 27 Nov 2006 19:04:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoqSS-0001iW-9e for pana@ietf.org; Mon, 27 Nov 2006 19:04:20 -0500 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoqSO-0004Ml-Rd for pana@ietf.org; Mon, 27 Nov 2006 19:04:20 -0500 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 kAS03XBN026717; Mon, 27 Nov 2006 19:03:33 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <456B7C84.2050204@tari.toshiba.com> Date: Mon, 27 Nov 2006 19:02:12 -0500 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Alper Yegin Subject: Re: [Pana] Preliminary pana-pana draft (13a) References: <0MKp2t-1GmXZL49QR-0003s9@mrelay.perfora.net> In-Reply-To: <0MKp2t-1GmXZL49QR-0003s9@mrelay.perfora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: 'Yoshihiro Ohba' , pana@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Hi Yoshi, Alper, I have some initial comments on pana-pana-13. I think the spec is much more simple now. Anyway, some minor comments below: * Sec 2. Terminology for Session Identifier Minor clarification. Is there any description on what properties a session identifier should have ? i.e. Should it be global and eternally unique as described previously in pana-pana-12 ? * Sec 4.6 Re-Authentication Phase, 2nd Paragraph, 5th sentence "Transmission of this error request is made optional in case this behavior is leveraged for ..." I'm not sure which error request the text is refering to. * Sec 5.2 Sequence Number and Retransmission, 6th Paragraph, 1st sentence "PANA messages are retransmitted based on a timer until ..." Minor editorial note, maybe better to clarify with "PANA request messages are retransmitted based on a timer until ..." * Sec 5.4 Message Authentication, Last Paragraph, last sentence "When the PaC does not support the integrity algorithm specified in the PANA-Bind-Request message, it MUST silently discard the message." Based on the ongoing changes in the PANA FSM doc, when the Pac silently discards PBR because of an un-supported algorithm and takes no other action, the PaC can get stuck in the same state forever despite the re-transmission of the PBR. The PAA eventually closes and cleans up because of failed re-transmission but the PaC may not since it may keep waiting for a good PBR. It maybe better to add text that says the PaC session should be close the session as well when a mis-match algorithm is found in the PBR. * Sec 6.1 IP and UDP Headers, 1st Paragraph, 1st sentence "Any PANA message is unicast between the PaC and the PAA." This is very minor and I'm not sure if this would be problematic but should we say that the pana message exchanges for a session be restricted to the same PaC interface ? This is in the case of multi-homed PaC. * Sec 8.5. Failed-Message-Header AVP, 1st Paragraph, 1st sentence "The Failed-Message-Header AVP (AVP Code 5) provides debugging information in cases where a request is rejected or not fully processed due to erroneous information in a specific AVP. .." Editorial. Maybe it the text meant ... "The Failed-Message-Header AVP (AVP Code 5) provides debugging information in cases where a message is rejected or not fully processed due to erroneous information its header." * Sec 8.8. Result-Code AVP, 1st Paragraph, Last sentence "Here are Result-Code AVP values taken from [RFC3588] and adapted for PANA." Should we still retain the last sentence above if Sec 8.8.2. does not really follow 3588 value mapping, i.e. there is no longer a distinction between protocol, permanent, ... etc categories. * Just a general question, Excerpt from Figure 1 is the exchange below: // Authentication and authorization phase <----- PANA-Auth-Request /* EAP Request */ -----> PANA-Auth-Answer In the example PAR/PAN exchange above. If for every transmission including re-transmission of the PAR, the corresponding PAN sent by the PaC gets lost. In this case the PAA will eventually give up and disconnect however the PaC does not have a way to know that the session failed and that it needs to cleanup. Sorry if this has already been addressed somewhere and I have not seen it yet. best regards, victor > Thank you Yoshi. > > Let's set a timer. PANA WG members: Please review and register your feedback > by the end of Nov 28 (one week). > > Alper > > > > > > > >> -----Original Message----- >> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] >> Sent: Sunday, November 19, 2006 10:39 AM >> To: pana@ietf.org >> Subject: [Pana] Preliminary pana-pana draft (13a) >> >> is available at: >> >> http://www.panasec.org/docs/editing/pana-spec.html >> >> (Now we get 17 pages reduction.) >> >> Please do sanity check to make sure that all resolutions discussed in >> IETF67 and over mailing list are reflected appropriately. Diff from >> revision 12 is also available. >> >> As soon as sanity check is done, I will submit a new revision (13) >> which is to be used for IETF last call. >> >> Regards, >> Yoshihiro Ohba >> >> _______________________________________________ >> Pana mailing list >> Pana@ietf.org >> https://www1.ietf.org/mailman/listinfo/pana > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Mon Nov 27 20:11:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GorUl-0002Of-Gp; Mon, 27 Nov 2006 20:10:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GorUk-0002LD-CY for pana@ietf.org; Mon, 27 Nov 2006 20:10:46 -0500 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GorUi-000860-Qj for pana@ietf.org; Mon, 27 Nov 2006 20:10:46 -0500 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id kAS1A3Eo026945; Mon, 27 Nov 2006 20:10:03 -0500 (EST) (envelope-from yohba@tari.toshiba.com) Date: Mon, 27 Nov 2006 20:10:05 -0500 To: Victor Fajardo Subject: Re: [Pana] Preliminary pana-pana draft (13a) Message-ID: <20061128011005.GD7823@steelhead> References: <0MKp2t-1GmXZL49QR-0003s9@mrelay.perfora.net> <456B7C84.2050204@tari.toshiba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <456B7C84.2050204@tari.toshiba.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 232 X-Spam-Score: -2.4 (--) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 Cc: 'Yoshihiro Ohba' , pana@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org On Mon, Nov 27, 2006 at 07:02:12PM -0500, Victor Fajardo wrote: > Hi Yoshi, Alper, > > I have some initial comments on pana-pana-13. I think the spec is much > more simple now. Anyway, some minor comments below: > > * Sec 2. Terminology for Session Identifier > > Minor clarification. Is there any description on what properties a > session identifier should have ? i.e. Should it be global and eternally > unique as described previously in pana-pana-12 ? It does not have to be global and eternally unique. It is just unique within PAA during the lifetime of the session. We can revise the text from: " Session Identifier: This identifier is used to uniquely identify a PANA session on the PaC and the PAA. It is included in PANA messages to bind the message to a specific PANA session. This bidirectional identifier is allocated by the PAA in handshake phase and freed when the session terminates. The session identifier is assigned by the PAA. " to: " Session Identifier: This identifier is used to uniquely identify a PANA session on the PaC and the PAA. It is included in PANA messages to bind the message to a specific PANA session. This bidirectional identifier is allocated by the PAA in handshake phase and freed when the session terminates. The session identifier is assigned by the PAA and unique within the PAA during the lifetime of the session. " > > * Sec 4.6 Re-Authentication Phase, 2nd Paragraph, 5th sentence > > "Transmission of this error request is made optional > in case this behavior is leveraged for ..." > > I'm not sure which error request the text is refering to. This is a leftover of pana-pana-12. We can safely delete this sentence. > > * Sec 5.2 Sequence Number and Retransmission, 6th Paragraph, 1st sentence > > "PANA messages are retransmitted based on a timer until ..." > > Minor editorial note, maybe better to clarify with > > "PANA request messages are retransmitted based on a timer until ..." > > * Sec 5.4 Message Authentication, Last Paragraph, last sentence > > "When the PaC does not support the integrity algorithm specified > in the PANA-Bind-Request message, it MUST silently discard the > message." > > Based on the ongoing changes in the PANA FSM doc, when the Pac > silently discards PBR because of an un-supported algorithm > and takes no other action, the PaC can get stuck in the same state > forever despite the re-transmission of the PBR. The PAA eventually > closes and cleans up because of failed re-transmission but the PaC > may not since it may keep waiting for a good PBR. It maybe better > to add text that says the PaC session should be close the session > as well when a mis-match algorithm is found in the PBR. Immediately terminating the session due to algorithm mismatch can be a place for DoS attack and is not good. We can use an explicit disconnect message from the other end, a finite session lifetime or failed liveness tests for clean up the session at the PaC side, by adopting the general session termination guidelines described in Section 3: " o Termination phase: The PaC or PAA may choose to discontinue the access service at any time. An explicit disconnect message can be sent by either end. If either the PaC or the PAA disconnects without engaging in termination messaging, it is expected that either the expiration of a finite session lifetime or failed liveness tests would clean up the session at the other end. " > > * Sec 6.1 IP and UDP Headers, 1st Paragraph, 1st sentence > > "Any PANA message is unicast between the PaC and the PAA." > > This is very minor and I'm not sure if this would be problematic > but should we say that the pana message exchanges for a session be > restricted to the same PaC interface ? This is in the case of > multi-homed PaC. Isn't this obvious according to the following definition? " PANA Session: A PANA session begins with the handshake between the PANA Client (PaC) and the PANA Authentication Agent (PAA), and terminates as a result of an authentication or liveness test failure, a message delivery failure after retransmissions reach maximum values, session lifetime expiration, or an explicit termination message. A fixed session identifier is maintained throughout a session. A session cannot be shared across multiple network interfaces. Only one IP address of the PaC is allowed to be bound to a PANA session for simplicity. " > > * Sec 8.5. Failed-Message-Header AVP, 1st Paragraph, 1st sentence > > "The Failed-Message-Header AVP (AVP Code 5) provides debugging > information in cases where a request is rejected or not fully > processed due to erroneous information in a specific AVP. .." > > Editorial. Maybe it the text meant ... > > "The Failed-Message-Header AVP (AVP Code 5) provides debugging > information in cases where a message is rejected or not fully > processed due to erroneous information its header." OK. Since errors can happen in AVPs or header or both, I'd revise the text something like: "The Failed-Message-Header AVP (AVP Code 5) provides debugging information in cases where a request is rejected or not fully processed due to erroneous information in the message." > > * Sec 8.8. Result-Code AVP, 1st Paragraph, Last sentence > > "Here are Result-Code AVP values taken from [RFC3588] and adapted > for PANA." > > Should we still retain the last sentence above if Sec 8.8.2. > does not really follow 3588 value mapping, i.e. there is no > longer a distinction between protocol, permanent, ... etc > categories. This is another leftover. We can change the text to: "Result-Code AVP values are described in the subsequent sections." > > * Just a general question, Excerpt from Figure 1 is the exchange below: > > // Authentication and authorization phase > <----- PANA-Auth-Request /* EAP Request */ > -----> PANA-Auth-Answer > > In the example PAR/PAN exchange above. If for every transmission > including re-transmission of the PAR, the corresponding PAN sent > by the PaC gets lost. In this case the PAA will eventually give up > and disconnect however the PaC does not have a way to know that > the session failed and that it needs to cleanup. Sorry if this > has already been addressed somewhere and I have not seen it yet. > Again this could be handled by adopting the general session termination guidelines described in Section 3. Yoshihiro Ohba > > best regards, > victor > > > > > >Thank you Yoshi. > > > >Let's set a timer. PANA WG members: Please review and register your > >feedback > >by the end of Nov 28 (one week). > > > >Alper > > > > > > > > > > > > > > > >>-----Original Message----- > >>From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > >>Sent: Sunday, November 19, 2006 10:39 AM > >>To: pana@ietf.org > >>Subject: [Pana] Preliminary pana-pana draft (13a) > >> > >>is available at: > >> > >>http://www.panasec.org/docs/editing/pana-spec.html > >> > >>(Now we get 17 pages reduction.) > >> > >>Please do sanity check to make sure that all resolutions discussed in > >>IETF67 and over mailing list are reflected appropriately. Diff from > >>revision 12 is also available. > >> > >>As soon as sanity check is done, I will submit a new revision (13) > >>which is to be used for IETF last call. > >> > >>Regards, > >>Yoshihiro Ohba > >> > >>_______________________________________________ > >>Pana mailing list > >>Pana@ietf.org > >>https://www1.ietf.org/mailman/listinfo/pana > > > > > >_______________________________________________ > >Pana mailing list > >Pana@ietf.org > >https://www1.ietf.org/mailman/listinfo/pana > > > > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Tue Nov 28 12:22:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp6eU-0001RT-Bn; Tue, 28 Nov 2006 12:21:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp6eT-0001RD-6w for pana@ietf.org; Tue, 28 Nov 2006 12:21:49 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp6eR-0005bs-PT for pana@ietf.org; Tue, 28 Nov 2006 12:21:49 -0500 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 18:21:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pana] AD review of draft-ietf-dhc-paa-option-04.txt Date: Tue, 28 Nov 2006 18:21:28 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026041811C0@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pana] AD review of draft-ietf-dhc-paa-option-04.txt Thread-Index: Acb83r0Ama5KdVBDQNydXoS88DyKywWJ8muA From: "MORAND Lionel RD-CORE-ISS" To: "Jari Arkko" , "Alper Yegin" X-OriginalArrivalTime: 28 Nov 2006 17:21:38.0439 (UTC) FILETIME=[A99D7970:01C71311] X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: pana@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Hi Jari, Alper According to the presentation made during the last IETF meeting, here = are the proposed changes to include in the next version of the PANA-DHCP = document. Please consider the proposed modifications to make sure that all the = remaining issues are covered. I will submit a new version of the draft (v05) based on your feedack. BR, Lionel ******************************************************************=20 #1- in the introduction (section 1), at the end of the 3rd paragraph, = revise the text to remove "many" From: =20 "This document specifies DHCPv4 [RFC2131] and DHCPv6 [RFC3315] = options that allow PANA client (PaC) to discover PANA Authentication Agents (PAA). This is one of the many methods for locating PAAs." To: "This document specifies DHCPv4 [RFC2131] and DHCPv6 [RFC3315] = options that allow PANA client (PaC) to discover PANA Authentication Agents (PAA). This is one of the methods for locating PAAs." #2- in the introduction (section 1), extend the existing section with = the following text: "The DHCP options defined in this document are used only as a PAA discovery mechanism. These DHCP options MUST NOT be used to perform=20 any negotiation on the use of PANA between the PaC and a PAA." #3- At the end of the section 4 (DHCPv4 option), revise the text to = clarify the use of the DHCP options: From: "A DHCPv4 client requests the PAA DHCPv4 Option in a Parameter = Request List as described in [RFC2131] and [RFC2132]. The DHCPv4 client MUST try the records in the order listed in the PAA DHCPv4 option." To: "A PaC (DHCPv4 client) SHOULD request the PAA DHCPv4 Option in a Parameter Request List as described in [RFC2131] and [RFC2132]. If configured with a (list of) PAA address(es), a DHCPv4 server = SHOULD send a client with the PAA DHCPv4 option, even if this option is not explicitly requested by the client. A PaC (DHCPv4 client) receiving the PAA DHCPv4 option SHOULD use the (list of) IP address(es) to locate PAA. The PaC (DHCPv4 client) MUST try the records in the order listed in=20 the PAA DHCPv4 option received from the DHCPv4 server." #4- At the end of the section 5 (DHCPv6 option), revise the text to = clarify the client/server behavior: From: "A DHCPv6 client requests the PAA DHCPv6 option in an Options Request Option (ORO) as described in the DHCPv6 specification [RFC3315]. The DHCPv6 client MUST try the records in the order listed in the PAA DHCPv6 option." To: "A PaC (DHCPv6 client) SHOULD request the PAA DHCPv6 option in an Options Request Option (ORO) as described in the DHCPv6 specification [RFC3315]. If configured with a (list of) PAA address(es), a DHCPv6 server = SHOULD send a client with the PAA DHCPv6 option, even if this option is not explicitly requested by the client. A PaC (DHCPv6 client) receiving the PAA DHCPv6 option SHOULD use the (list of) IP address(es) to locate PAA. The PaC (DHCPv6 client) MUST try the records in the order listed in = the PAA DHCPv6 option." > -----Message d'origine----- > De : Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Envoy=E9 : mardi 31 octobre 2006 12:22 > =C0 : Alper Yegin; MORAND Lionel RD-CORE-ISS > Cc : pana@ietf.org > Objet : Re: [Pana] AD review of draft-ietf-dhc-paa-option-04.txt >=20 > I am fine with the approach that the option is merely for PAA=20 > address discovery, not affecting whether PANA is on or not.=20 > But I would like that to be explicitly stated in the=20 > document. It would also be useful to have a warning that=20 > there are issues if you attempt to do otherwise. >=20 > Changes needed to state are likely fairly small. > If you submit the draft it probably appears when the IETF=20 > starts and I can move the draft along after that. > > "A PaC SHOULD request the PAA DHCPv4 Option in a Parameter Request=20 > > List as described in [RFC2131] and [RFC2132]. > > If configured with a (list of) PAA address(es), a DHCPv4=20 > server SHOULD=20 > > send a client with the PAA DHCPv4 option, even if this=20 > option is not=20 > > explicitly requested by the client." > This is a start. It defines what the nodes do, but I would=20 > also like to see >=20 > 1) What the PaC does when it receives the option > 2) Explanation that the option is not used for turning PANA=20 > on/off, along with the warning >=20 > --Jari >=20 >=20 _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Tue Nov 28 20:37:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpENg-0003FR-L3; Tue, 28 Nov 2006 20:37:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpENf-0003FM-A9 for pana@ietf.org; Tue, 28 Nov 2006 20:36:59 -0500 Received: from mail.um.es ([155.54.212.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpENa-0003KV-Ot for pana@ietf.org; Tue, 28 Nov 2006 20:36:59 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id B01931FA9E9; Wed, 29 Nov 2006 02:36:51 +0100 (CET) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 24956-01-28; Wed, 29 Nov 2006 02:36:49 +0100 (CET) Received: from [192.168.0.3] (84-121-77-42.onocable.ono.com [84.121.77.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.um.es (Postfix) with ESMTP id 8DF281FA87A; Wed, 29 Nov 2006 02:36:37 +0100 (CET) Message-ID: <456CE41E.1020607@dif.um.es> Date: Wed, 29 Nov 2006 02:36:30 +0100 From: Rafa Marin Lopez Organization: University of Murcia User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org Subject: Re: [Pana] Preliminary pana-pana draft (13a) References: <0MKp2t-1GmXZL49QR-0003s9@mrelay.perfora.net> In-Reply-To: <0MKp2t-1GmXZL49QR-0003s9@mrelay.perfora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: Rafa Marin Lopez X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Hi Yoshi,Alper, all I have been reviewing the doc.In general, it is ok for me. Only some two minor comments: Page 13: "The MSK and the PANA session MUST be deleted immediately after the PANA-Bind message exchange." I think I missed something...could anybody point me where this was discussed to understand the reason behind? or is it a mistake? Initially i think PANA session should not be removed. On the other hand, with this text PANA does not allow MSK caching. Taking into account all references to bootstrapp security has been removed it seems coherent because MSK won't be used further. However, i was wondering why this limitation. Section 4.4. says : "A Nonce AVP MUST be included in the first PANA-Auth-Request and PANA- Auth-Answer messages." However , Figure 9 (table) has 0-1 for PAR/PAN I guess it should be 1 taking into account the text above (on the other hand, that Nonce AVP would not be needed if EAP method is not able to generate cryptographic material) Best Regards. Alper Yegin wrote: >Thank you Yoshi. > >Let's set a timer. PANA WG members: Please review and register your feedback >by the end of Nov 28 (one week). > >Alper > > > > > > > > > >>-----Original Message----- >>From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] >>Sent: Sunday, November 19, 2006 10:39 AM >>To: pana@ietf.org >>Subject: [Pana] Preliminary pana-pana draft (13a) >> >>is available at: >> >>http://www.panasec.org/docs/editing/pana-spec.html >> >>(Now we get 17 pages reduction.) >> >>Please do sanity check to make sure that all resolutions discussed in >>IETF67 and over mailing list are reflected appropriately. Diff from >>revision 12 is also available. >> >>As soon as sanity check is done, I will submit a new revision (13) >>which is to be used for IETF last call. >> >>Regards, >>Yoshihiro Ohba >> >>_______________________________________________ >>Pana mailing list >>Pana@ietf.org >>https://www1.ietf.org/mailman/listinfo/pana >> >> > > >_______________________________________________ >Pana mailing list >Pana@ietf.org >https://www1.ietf.org/mailman/listinfo/pana > > > > -- ------------------------------------------------------ Rafael Marin Lopez Depto. Ing. de la Info. y las Comunicaciones Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34968398501 e-mail: rafa@dif.um.es ------------------------------------------------------ _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Wed Nov 29 14:15:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpUtj-00013x-2X; Wed, 29 Nov 2006 14:15:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpUti-00013q-FL for pana@ietf.org; Wed, 29 Nov 2006 14:15:10 -0500 Received: from imx12.toshiba.co.jp ([61.202.160.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpUtb-00055j-OR for pana@ietf.org; Wed, 29 Nov 2006 14:15:10 -0500 Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx12.toshiba.co.jp with ESMTP id kATJEPoi018395; Thu, 30 Nov 2006 04:14:25 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id kATJEOsA020777; Thu, 30 Nov 2006 04:14:24 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with ESMTP id EAA20776; Thu, 30 Nov 2006 04:14:24 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id kATJENHk022420; Thu, 30 Nov 2006 04:14:24 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id kATJENw6000628; Thu, 30 Nov 2006 04:14:23 +0900 (JST) Received: from steelhead ([172.30.24.105]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J9I0040GARW7M90@mail.po.toshiba.co.jp>; Thu, 30 Nov 2006 04:14:23 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.63) (envelope-from ) id 1GpUsr-0000GK-SR; Wed, 29 Nov 2006 11:14:17 -0800 Date: Wed, 29 Nov 2006 14:14:17 -0500 From: Yoshihiro Ohba Subject: Re: [Pana] Preliminary pana-pana draft (13a) In-reply-to: <456CE41E.1020607@dif.um.es> To: Rafa Marin Lopez Message-id: <20061129191417.GC30901@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <0MKp2t-1GmXZL49QR-0003s9@mrelay.perfora.net> <456CE41E.1020607@dif.um.es> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: 'Yoshihiro Ohba' , pana@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Hi Rafa, Thank you for the review. Please see my comment below. On Wed, Nov 29, 2006 at 02:36:30AM +0100, Rafa Marin Lopez wrote: > Hi Yoshi,Alper, all > > I have been reviewing the doc.In general, it is ok for me. > > Only some two minor comments: > > Page 13: > > "The MSK and the PANA session MUST be deleted > immediately after the PANA-Bind message exchange." > > I think I missed something...could anybody point me where this was > discussed to understand the reason behind? or is it a mistake? > > Initially i think PANA session should not be removed. On the other hand, > with this text PANA does not allow MSK caching. Taking into account all > references to bootstrapp security > has been removed it seems coherent because MSK won't be used further. > However, i was wondering why this limitation. Note that the above behavior is in the context of the following case: " There is a case where EAP authentication succeeds with producing an EAP Success message but network access authorization fails due to, e.g., authorization rejected by a AAA or authorization locally rejected by the PAA. " This means, if authorization fails then the PANA session must be deleted even if the EAP authentication has succeeded. So the current text should be ok. > > > Section 4.4. says : > > "A Nonce AVP MUST be included in the first PANA-Auth-Request and PANA- > Auth-Answer messages." > > However , Figure 9 (table) has 0-1 for PAR/PAN > > I guess it should be 1 taking into account the text above (on the other > hand, that Nonce AVP would not be needed if EAP method is not able to > generate cryptographic material) It is true that Nonce AVP will not be used if MSK is not generated. However, since PANA layer should not know which EAP method is in use or is able to generate MSK, the only way is to mandate Nonce AVP in the first PAR/PAN exchange. The occurence table stating that Nonce AVP is 0-1 for PAR/PAN is correct. This is because Nonce AVP is carried only in the first PAR/PAN exchange in authentication and authorization phase and re-authentication phase, and it is not carried in other PAR/PAN exchanges. Yoshihiro Ohba > > Best Regards. > > Alper Yegin wrote: > > >Thank you Yoshi. > > > >Let's set a timer. PANA WG members: Please review and register your > >feedback > >by the end of Nov 28 (one week). > > > >Alper > > > > > > > > > > > > > > > > > > > >>-----Original Message----- > >>From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > >>Sent: Sunday, November 19, 2006 10:39 AM > >>To: pana@ietf.org > >>Subject: [Pana] Preliminary pana-pana draft (13a) > >> > >>is available at: > >> > >>http://www.panasec.org/docs/editing/pana-spec.html > >> > >>(Now we get 17 pages reduction.) > >> > >>Please do sanity check to make sure that all resolutions discussed in > >>IETF67 and over mailing list are reflected appropriately. Diff from > >>revision 12 is also available. > >> > >>As soon as sanity check is done, I will submit a new revision (13) > >>which is to be used for IETF last call. > >> > >>Regards, > >>Yoshihiro Ohba > >> > >>_______________________________________________ > >>Pana mailing list > >>Pana@ietf.org > >>https://www1.ietf.org/mailman/listinfo/pana > >> > >> > > > > > >_______________________________________________ > >Pana mailing list > >Pana@ietf.org > >https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > -- > ------------------------------------------------------ > Rafael Marin Lopez > Depto. Ing. de la Info. y las Comunicaciones > Faculty of Computer Science-University of Murcia > 30100 Murcia - Spain > Telf: +34968398501 e-mail: rafa@dif.um.es > ------------------------------------------------------ > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Thu Nov 30 10:44:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpo4x-0005II-2O; Thu, 30 Nov 2006 10:44:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpo4w-0005IC-0x for pana@ietf.org; Thu, 30 Nov 2006 10:44:02 -0500 Received: from mout.perfora.net ([217.160.230.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpo4r-0006QB-MJ for pana@ietf.org; Thu, 30 Nov 2006 10:44:02 -0500 Received: from [85.96.27.150] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrelayus1) with ESMTP (Nemesis), id 0MKp2t-1Gpo4m1muu-0003sR; Thu, 30 Nov 2006 10:43:55 -0500 From: "Alper Yegin" To: "'Yoshihiro Ohba'" , Subject: RE: [Pana] Preliminary pana-pana draft (13a) Date: Thu, 30 Nov 2006 17:43:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AccNA8viG80KCD8rRnqXTgeVPuq5rQHkZNWQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <20061119083903.GC31177@steelhead> Message-ID: <0MKp2t-1Gpo4m1muu-0003sR@mrelay.perfora.net> X-Provags-ID: perfora.net abuse@perfora.net login:abf7a4bb310ea4dfc9b6841113e2970f X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Yoshi, Thanks a lot for the revision. Here I have few comments and suggestions. By the virtue of enabling transport of EAP above IP, any authentication method that can be carried as an EAP method is made available to PANA and hence to any link-layer technology with a minimum link-layer dependency. There is a clear Alper> What's that dependency? There are components that are part of a complete secure network access solution but are outside of the PANA protocol specification, including IP address configuration, authentication method choice, data traffic protection, PAA-EP protocol, and PAA discovery. PANA authentication output is used for creating access control filters. These components except for IP address configuration are described in separate documents (see [I-D.ietf-pana-framework], [I-D.ietf-pana-snmp] and [I-D.ietf-dhc-paa-option]). The IP address configuration component may be specified in deployment-specific PANA applicability documents. The readers are recommended to read the PANA Framework document [I-D.ietf-pana-framework] prior to reading this protocol specification document. Alper> "IP address configuration" is not really part of a secure network access solution. I'd recommend this re-write of the above paragraph: There are components that are part of a complete secure network access solution but are outside of the PANA protocol specification, including authentication method choice, data traffic protection, PAA-EP protocol, and PAA discovery. PANA authentication output is used for creating access control filters. These components are described in separate documents (see [I-D.ietf-pana-framework], [I-D.ietf-pana-snmp] and [I-D.ietf-dhc-paa-option]). The readers are recommended to read the PANA Framework document [I-D.ietf-pana-framework] prior to reading this protocol specification document. The protocol entity in the access network whose responsibility is to verify the credentials provided by a PANA client (PaC) and authorize network access to the access device associated with the client. The PAA and the EAP authenticator (and optionally the EAP Alper> I'd remove "associated with the client." session cannot be shared across multiple network interfaces. Only one IP address of the PaC is allowed to be bound to a PANA session for simplicity. Alper> i think we can remove the last sentence. Sure we don't explicitly support multi-homed clients, but no need to explicitly limit to single-homed either. Being silent is a better choice. The PAA MAY refrain from retransmitting the PANA-Start-Request message to maintain as less amount of state as possible in the handshake phase. For this reason, the PaC MUST retransmit the PANA- Client-Initiation message until it enters the authentication and authorization phase by receiving a PANA-Auth-Request message from the PAA. Alper> Just to add a bit more elaboration (to prevent questions), I can recommend In order to prevent potential DoS attacks, the PAA MAY refrain from timeout-based retransmission of the PANA-Start-Request message in response to a PaC-initiated handshake. For this reason, the PaC MUST retransmit the PANA-Client-Initiation message until it enters the authentication and authorization phase by receiving the first PANA-Auth-Request message from the PAA. session, it MUST silently discard the message. Transmission of this error request is made optional in case this behavior is leveraged for a DoS attack on the PAA. A Nonce AVP MUST be included in the first Alper> There is no more error message generation. Hence the sentence starting with "Transmission of this..." shall be deleted. If IPsec is used between the PaC and the EPs, an IKE [RFC2409] IKEv2 [RFC4306] or MOBIKE [RFC4555] run is needed following such a change. Alper> This is not something for the base PANA specification to state. It's for PANA-ipsec document. Let's remove the above paragraph. messages MUST be protected with an AUTH AVP. The PAA may also need update the per-packet enforcement policies of the EPs, however, this is out of the scope of this document. Alper> This last sentence shall be removed too. As you said, it's out of scope. For other PANA messages, the source port MUST be set to a value chosen by the sender. and the destination port MUST be set to the Alper> Remove "." [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. Alper> this shall be under the informative references. Thank you. Alper > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Sunday, November 19, 2006 10:39 AM > To: pana@ietf.org > Subject: [Pana] Preliminary pana-pana draft (13a) > > is available at: > > http://www.panasec.org/docs/editing/pana-spec.html > > (Now we get 17 pages reduction.) > > Please do sanity check to make sure that all resolutions discussed in > IETF67 and over mailing list are reflected appropriately. Diff from > revision 12 is also available. > > As soon as sanity check is done, I will submit a new revision (13) > which is to be used for IETF last call. > > Regards, > Yoshihiro Ohba > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Thu Nov 30 11:15:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpoZ0-0004uE-Mv; Thu, 30 Nov 2006 11:15:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpoYz-0004u4-EI for pana@ietf.org; Thu, 30 Nov 2006 11:15:05 -0500 Received: from imx12.toshiba.co.jp ([61.202.160.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpoYs-0001lX-Od for pana@ietf.org; Thu, 30 Nov 2006 11:15:05 -0500 Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx12.toshiba.co.jp with ESMTP id kAUGEkH3017683; Fri, 1 Dec 2006 01:14:46 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id kAUGEkoG002228; Fri, 1 Dec 2006 01:14:46 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with ESMTP id BAA02227; Fri, 1 Dec 2006 01:14:45 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id kAUGEjrd017857; Fri, 1 Dec 2006 01:14:45 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id kAUGEjK5029370; Fri, 1 Dec 2006 01:14:45 +0900 (JST) Received: from steelhead ([172.30.24.105]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J9J00AXLX4I7300@mail.po.toshiba.co.jp>; Fri, 01 Dec 2006 01:14:45 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.63) (envelope-from ) id 1GpoYe-00038Z-3F; Thu, 30 Nov 2006 08:14:44 -0800 Date: Thu, 30 Nov 2006 11:14:43 -0500 From: Yoshihiro Ohba Subject: Re: [Pana] Preliminary pana-pana draft (13a) In-reply-to: <0MKp2t-1Gpo4m1muu-0003sR@mrelay.perfora.net> To: Alper Yegin Message-id: <20061130161443.GB10356@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <20061119083903.GC31177@steelhead> <0MKp2t-1Gpo4m1muu-0003sR@mrelay.perfora.net> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: 'Yoshihiro Ohba' , pana@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org On Thu, Nov 30, 2006 at 05:43:48PM +0200, Alper Yegin wrote: > > Yoshi, > > Thanks a lot for the revision. > > Here I have few comments and suggestions. > > > By the virtue of enabling transport of EAP > above IP, any authentication method that can be carried as an EAP > method is made available to PANA and hence to any link-layer > technology with a minimum link-layer dependency. There is a clear > > > Alper> What's that dependency? There is no link-layer dependency in the PANA protocol itself but there is some link-layer dependency in the entire PANA framework including EP which can be link-layer devices according to pana-framework I-D. Perhaps we can remove "with a minimum link-layer dependency" since this I-D is about the PANA protocol itself. > > > > There are components that are part of a complete secure network > access solution but are outside of the PANA protocol specification, > including IP address configuration, authentication method choice, > data traffic protection, PAA-EP protocol, and PAA discovery. PANA > authentication output is used for creating access control filters. > These components except for IP address configuration are described in > separate documents (see [I-D.ietf-pana-framework], > [I-D.ietf-pana-snmp] and [I-D.ietf-dhc-paa-option]). The IP address > configuration component may be specified in deployment-specific PANA > applicability documents. The readers are recommended to read the > PANA Framework document [I-D.ietf-pana-framework] prior to reading > this protocol specification document. > > Alper> "IP address configuration" is not really part of a secure network > access solution. I'd recommend this re-write of the above paragraph: > > There are components that are part of a complete secure network > access solution but are outside of the PANA protocol specification, > including authentication method choice, > data traffic protection, PAA-EP protocol, and PAA discovery. PANA > authentication output is used for creating access control filters. > These components are described in > separate documents (see [I-D.ietf-pana-framework], > [I-D.ietf-pana-snmp] and [I-D.ietf-dhc-paa-option]). > The readers are recommended to read the > PANA Framework document [I-D.ietf-pana-framework] prior to reading > this protocol specification document. OK. > > > > The protocol entity in the access network whose responsibility is > to verify the credentials provided by a PANA client (PaC) and > authorize network access to the access device associated with the > client. The PAA and the EAP authenticator (and optionally the EAP > > Alper> I'd remove "associated with the client." OK. > > > session cannot be shared across multiple network interfaces. Only > one IP address of the PaC is allowed to be bound to a PANA session > for simplicity. > > Alper> i think we can remove the last sentence. Sure we don't explicitly > support multi-homed clients, but no need to explicitly limit to single-homed > either. Being silent is a better choice. I agree. > > > > The PAA MAY refrain from retransmitting the PANA-Start-Request > message to maintain as less amount of state as possible in the > handshake phase. For this reason, the PaC MUST retransmit the PANA- > Client-Initiation message until it enters the authentication and > authorization phase by receiving a PANA-Auth-Request message from the > PAA. > > > Alper> Just to add a bit more elaboration (to prevent questions), I can > recommend > > > In order to prevent potential DoS attacks, the PAA MAY refrain from > timeout-based retransmission of the PANA-Start-Request > message in response to a PaC-initiated handshake. For this reason, > the PaC MUST retransmit the PANA-Client-Initiation message until it > enters the authentication and authorization phase by receiving > the first PANA-Auth-Request message from the PAA. OK. > > > > session, it MUST silently discard the message. Transmission of this > error request is made optional in case this behavior is leveraged for > a DoS attack on the PAA. A Nonce AVP MUST be included in the first > > > Alper> There is no more error message generation. Hence the sentence > starting with "Transmission of this..." shall be deleted. Yes (and there is similar comment from Victor). > > > If IPsec is used between the PaC and the EPs, an IKE [RFC2409] IKEv2 > [RFC4306] or MOBIKE [RFC4555] run is needed following such a change. > > Alper> This is not something for the base PANA specification to state. It's > for PANA-ipsec document. Let's remove the above paragraph. OK. > > > messages MUST be protected with an AUTH AVP. The PAA may also need > update the per-packet enforcement policies of the EPs, however, this > is out of the scope of this document. > > Alper> This last sentence shall be removed too. As you said, it's out of > scope. OK. > > > For other PANA messages, the source port MUST be set to a value > chosen by the sender. and the destination port MUST be set to the > > Alper> Remove "." OK. > > > [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., > and M. Carney, "Dynamic Host Configuration Protocol for > IPv6 (DHCPv6)", RFC 3315, July 2003. > > > Alper> this shall be under the informative references. OK. Regards, Yoshihiro Ohba > > > Thank you. > > Alper > > > > > -----Original Message----- > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > Sent: Sunday, November 19, 2006 10:39 AM > > To: pana@ietf.org > > Subject: [Pana] Preliminary pana-pana draft (13a) > > > > is available at: > > > > http://www.panasec.org/docs/editing/pana-spec.html > > > > (Now we get 17 pages reduction.) > > > > Please do sanity check to make sure that all resolutions discussed in > > IETF67 and over mailing list are reflected appropriately. Diff from > > revision 12 is also available. > > > > As soon as sanity check is done, I will submit a new revision (13) > > which is to be used for IETF last call. > > > > Regards, > > Yoshihiro Ohba > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Thu Nov 30 12:26:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gppg5-0005YH-Nn; Thu, 30 Nov 2006 12:26:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gppg4-0005VL-Lh for pana@ietf.org; Thu, 30 Nov 2006 12:26:28 -0500 Received: from mout.perfora.net ([217.160.230.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gppg3-0002HO-Cw for pana@ietf.org; Thu, 30 Nov 2006 12:26:28 -0500 Received: from [85.96.27.150] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrelayus1) with ESMTP (Nemesis), id 0MKp2t-1Gppft3I77-0003sC; Thu, 30 Nov 2006 12:26:23 -0500 From: "Alper Yegin" To: "'MORAND Lionel RD-CORE-ISS'" , "'Jari Arkko'" Subject: RE: [Pana] AD review of draft-ietf-dhc-paa-option-04.txt Date: Thu, 30 Nov 2006 19:26:13 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acb83r0Ama5KdVBDQNydXoS88DyKywWJ8muAAGdjo4A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB026041811C0@FTRDMEL2.rd.francetelecom.fr> Message-ID: <0MKp2t-1Gppft3I77-0003sC@mrelay.perfora.net> X-Provags-ID: perfora.net abuse@perfora.net login:abf7a4bb310ea4dfc9b6841113e2970f X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: pana@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Hi Lionel, Thank you for the updates. > #2- in the introduction (section 1), extend the existing section with = the > following text: >=20 > "The DHCP options defined in this document are used only as a PAA > discovery mechanism. These DHCP options MUST NOT be used to perform > any negotiation on the use of PANA between the PaC and a PAA." Would replacing the second sentence with the one below improve clarity? Presence of these DHCP options does not indicate PANA must be used in=20 the network. Others look good. Alper >=20 > #3- At the end of the section 4 (DHCPv4 option), revise the text to > clarify the use of the DHCP options: >=20 > From: >=20 > "A DHCPv4 client requests the PAA DHCPv4 Option in a Parameter = Request > List as described in [RFC2131] and [RFC2132]. >=20 > The DHCPv4 client MUST try the records in the order listed in the = PAA > DHCPv4 option." >=20 > To: >=20 > "A PaC (DHCPv4 client) SHOULD request the PAA DHCPv4 Option in a > Parameter Request List as described in [RFC2131] and [RFC2132]. >=20 > If configured with a (list of) PAA address(es), a DHCPv4 server = SHOULD > send a client with the PAA DHCPv4 option, even if this option is = not > explicitly requested by the client. >=20 > A PaC (DHCPv4 client) receiving the PAA DHCPv4 option SHOULD use = the > (list of) IP address(es) to locate PAA. >=20 > The PaC (DHCPv4 client) MUST try the records in the order listed in > the PAA DHCPv4 option received from the DHCPv4 server." >=20 > #4- At the end of the section 5 (DHCPv6 option), revise the text to > clarify the client/server behavior: >=20 > From: >=20 > "A DHCPv6 client requests the PAA DHCPv6 option in an Options = Request > Option (ORO) as described in the DHCPv6 specification [RFC3315]. >=20 > The DHCPv6 client MUST try the records in the order listed in the = PAA > DHCPv6 option." >=20 > To: >=20 > "A PaC (DHCPv6 client) SHOULD request the PAA DHCPv6 option in an > Options Request Option (ORO) as described in the DHCPv6 = specification > [RFC3315]. >=20 > If configured with a (list of) PAA address(es), a DHCPv6 server = SHOULD > send a client with the PAA DHCPv6 option, even if this option is = not > explicitly requested by the client. >=20 > A PaC (DHCPv6 client) receiving the PAA DHCPv6 option SHOULD use = the > (list of) IP address(es) to locate PAA. >=20 > The PaC (DHCPv6 client) MUST try the records in the order listed in = the > PAA DHCPv6 option." >=20 >=20 >=20 >=20 > > -----Message d'origine----- > > De : Jari Arkko [mailto:jari.arkko@piuha.net] > > Envoy=E9 : mardi 31 octobre 2006 12:22 > > =C0 : Alper Yegin; MORAND Lionel RD-CORE-ISS > > Cc : pana@ietf.org > > Objet : Re: [Pana] AD review of draft-ietf-dhc-paa-option-04.txt > > > > I am fine with the approach that the option is merely for PAA > > address discovery, not affecting whether PANA is on or not. > > But I would like that to be explicitly stated in the > > document. It would also be useful to have a warning that > > there are issues if you attempt to do otherwise. > > > > Changes needed to state are likely fairly small. > > If you submit the draft it probably appears when the IETF > > starts and I can move the draft along after that. > > > "A PaC SHOULD request the PAA DHCPv4 Option in a Parameter Request > > > List as described in [RFC2131] and [RFC2132]. > > > If configured with a (list of) PAA address(es), a DHCPv4 > > server SHOULD > > > send a client with the PAA DHCPv4 option, even if this > > option is not > > > explicitly requested by the client." > > This is a start. It defines what the nodes do, but I would > > also like to see > > > > 1) What the PaC does when it receives the option > > 2) Explanation that the option is not used for turning PANA > > on/off, along with the warning > > > > --Jari > > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Thu Nov 30 13:21:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpqWv-0007jw-Cj; Thu, 30 Nov 2006 13:21:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpqWt-0007j9-L9 for pana@ietf.org; Thu, 30 Nov 2006 13:21:03 -0500 Received: from web80605.mail.yahoo.com ([66.218.79.94]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GpqWo-00016n-80 for pana@ietf.org; Thu, 30 Nov 2006 13:21:03 -0500 Received: (qmail 97754 invoked by uid 60001); 30 Nov 2006 18:20:57 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=dBc44ScPo9l/VrTb33qCmKsEU8EEM/iznotPOyn6FV58AKMDyXEO3Fx26iVmEnRkfnR9gkM1bfxS2MSxLwjWj8l/8+ZsaBJBIYvh/OOipTLPHWOEAVAZ0Gp+JDdRCw2bmBFMbMRi1BwyUJxfnXSYJf8AgVmFpZsjt7MX7WivrCk= ; Message-ID: <20061130182057.97752.qmail@web80605.mail.yahoo.com> Received: from [206.132.194.3] by web80605.mail.yahoo.com via HTTP; Thu, 30 Nov 2006 10:20:57 PST Date: Thu, 30 Nov 2006 10:20:57 -0800 (PST) From: Mohan Parthasarathy To: yohba@tari.toshiba.com MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: pana@ietf.org Subject: [Pana] Re: review pana spec X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Hi Yoshi,=0A=0Athe draft looks pretty good. I mainly went through the diffe= rences. Here are my comments. =0A=0A- Abstract calls it "link-layer" agnost= ic where as in the Introduction, there is=0A "minimum" link-layer dependen= cy. Having gone through this discussion many=0A times it might be better t= o remove both these terms to avoid lengthy discussions :-)=0A=0A-Why isn't = Key-Id included in the PANA-AUTH-KEY ? If you have multiple MSKs, isn't the= re=0A multiple PANA SAs and hence the Key-Id should be included ?=0A=0A-Se= ction 5.6 " Pac Updating its IP addresses" : Is this needed for basic opera= tion of PANA ?=0A The example given in the section makes me believe that it= is not required. But it is required=0A depending on what IP address you st= art with. Hence, some clarification is required.=0A=0A-In the Security cons= iderations, =0A 11.8. IP Address Spoofing=0A=0A There is no w= ay to prove the ownership of the IP address presented by=0A the = PaC. Hence an authorized PaC can launch a redirect attack by=0A = spoofing a victim's IP address.=0A=0A the first sentence is worded in suc= h a way that there is no way to do it. But if SEND=0A is deployed in acces= s networks, then it should be possible. Sure, PANA by itself=0A cannot do = it.=0A=0A=0A=0A-mohan=0A=0A=0A=0A=0A=0A=0A=0A=0A> -----Original Message----= -=0A> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]=0A> Sent: Sunday= , November 19, 2006 10:39 AM=0A> To: pana@ietf.org=0A> Subject: [Pana] Prel= iminary pana-pana draft (13a)=0A> =0A> is available at:=0A> =0A> http://www= .panasec.org/docs/editing/pana-spec.html=0A> =0A> (Now we get 17 pages redu= ction.)=0A> =0A> Please do sanity check to make sure that all resolutions d= iscussed in=0A> IETF67 and over mailing list are reflected appropriately. = Diff from=0A> revision 12 is also available.=0A> =0A> As soon as sanity che= ck is done, I will submit a new revision (13)=0A> which is to be used for I= ETF last call.=0A> =0A> Regards,=0A> Yoshihiro Ohba=0A> =0A> ______________= _________________________________=0A> Pana mailing list=0A> Pana@ietf.org= =0A> https://www1.ietf.org/mailman/listinfo/pana=0A=0A=0A=0A _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Thu Nov 30 15:08:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpsCR-0003NI-F3; Thu, 30 Nov 2006 15:08:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpsCQ-0003NC-En for pana@ietf.org; Thu, 30 Nov 2006 15:08:02 -0500 Received: from inet-tsb5.toshiba.co.jp ([202.33.96.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpsCG-0005l9-Nm for pana@ietf.org; Thu, 30 Nov 2006 15:08:02 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb5.toshiba.co.jp with ESMTP id kAUK7or2000522; Fri, 1 Dec 2006 05:07:50 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id kAUK7oII011027; Fri, 1 Dec 2006 05:07:50 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with ESMTP id FAA11025; Fri, 1 Dec 2006 05:07:50 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id kAUK7nWI029202; Fri, 1 Dec 2006 05:07:49 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id kAUK7nZD027641; Fri, 1 Dec 2006 05:07:49 +0900 (JST) Received: from steelhead ([172.30.24.105]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J9K00AUK7WY6X10@mail.po.toshiba.co.jp>; Fri, 01 Dec 2006 05:07:49 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.63) (envelope-from ) id 1GpsCC-0004Kf-8O; Thu, 30 Nov 2006 12:07:48 -0800 Date: Thu, 30 Nov 2006 15:07:48 -0500 From: Yoshihiro Ohba Subject: Re: [Pana] Re: review pana spec In-reply-to: <20061130182057.97752.qmail@web80605.mail.yahoo.com> To: Mohan Parthasarathy Message-id: <20061130200748.GG10356@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <20061130182057.97752.qmail@web80605.mail.yahoo.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: yohba@tari.toshiba.com, pana@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org On Thu, Nov 30, 2006 at 10:20:57AM -0800, Mohan Parthasarathy wrote: > Hi Yoshi, > > the draft looks pretty good. I mainly went through the differences. Here are my comments. > > - Abstract calls it "link-layer" agnostic where as in the Introduction, there is > "minimum" link-layer dependency. Having gone through this discussion many > times it might be better to remove both these terms to avoid lengthy discussions :-) For Abstract, we can replace "link-layer agnostic transport" with "network layer transport". For Introduction we can remove "minimum link-layer dependency". > > -Why isn't Key-Id included in the PANA-AUTH-KEY ? If you have multiple MSKs, isn't there > multiple PANA SAs and hence the Key-Id should be included ? Thank you for pointing this out. You are right, Key-Id needs to be included. We can revise the text to: " PANA_AUTH_KEY = prf+(MSK, PaC_nonce | PAA_nonce | Session_ID | Key_ID) where the prf+ function is defined in IKEv2 [RFC4306]. The pseudo- random function to be used for the prf+ function is specified in the Algorithm AVP in a PANA-Bind-Request message. The length of PANA_AUTH_KEY depends on the integrity algorithm in use. See Section 5.4 for the detailed usage of the PANA_AUTH_KEY. PaC_nonce and PAA_nonce are values of the Nonce AVP carried in the first PANA- Auth-Answer and PANA-Auth-Request messages in the authentication and authorization phase or the re-authentication phase, respectively. Session_ID is the session identifier of the session. Key_ID is the value of the Key-ID AVP. " > -Section 5.6 " Pac Updating its IP addresses" : Is this needed for basic operation of PANA ? > The example given in the section makes me believe that it is not required. But it is required > depending on what IP address you start with. Hence, some clarification is required. Perhaps what we need to say is that PaC needs to update its IP address *used for PANA*. (We don't need to say which IP address is used for PANA, which may be described by deployment-specific PANA applicability documents.) Here is revised text for Section 5.6 (also reflecting Alper's comment): " 5.6. PaC Updating its IP Address A PaC's IP address used for PANA can change in certain situations, e.g., when the PaC moves from one IP link to another within the same PAA's realm. In order to maintain the PANA session, the PAA needs to be notified about the change of PaC address. In order to maintain the PANA session, the PAA needs to be notified about the change of the IP address of the PaC. After the PaC has changed its IP address used for PANA, it MUST send a PANA-Update-Request message to the PAA. The PAA MUST update the PANA session with the new PaC address carried in the Source Address field of the IP header and return a PANA-Update-Answer message. If there is an established PANA SA, both PANA-Update-Request and PANA-Update-Answer messages MUST be protected with an AUTH AVP. " > > -In the Security considerations, > 11.8. IP Address Spoofing > > There is no way to prove the ownership of the IP address presented by > the PaC. Hence an authorized PaC can launch a redirect attack by > spoofing a victim's IP address. > > the first sentence is worded in such a way that there is no way to do it. But if SEND > is deployed in access networks, then it should be possible. Sure, PANA by itself > cannot do it. You are right. Also, an unauthorized PaC as well as authorized PaC can launch the attack. How about the following text? " 11.8. IP Address Spoofing Without use of SEND (SEcure Neighbor Discovery [RFC 3971], there is no way to prove the ownership of the IP address presented by the PaC. Hence an attacker can launch a redirect attack by spoofing a victim's IP address. It is RECOMMENDED to use SEND to avoid such an attack. " Regards, Yoshihiro Ohba > > > > -mohan > > > > > > > > > > -----Original Message----- > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > Sent: Sunday, November 19, 2006 10:39 AM > > To: pana@ietf.org > > Subject: [Pana] Preliminary pana-pana draft (13a) > > > > is available at: > > > > http://www.panasec.org/docs/editing/pana-spec.html > > > > (Now we get 17 pages reduction.) > > > > Please do sanity check to make sure that all resolutions discussed in > > IETF67 and over mailing list are reflected appropriately. Diff from > > revision 12 is also available. > > > > As soon as sanity check is done, I will submit a new revision (13) > > which is to be used for IETF last call. > > > > Regards, > > Yoshihiro Ohba > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Thu Nov 30 16:53:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GptqT-0007Hw-Iu; Thu, 30 Nov 2006 16:53:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GptqS-0007Hq-Jf for pana@ietf.org; Thu, 30 Nov 2006 16:53:28 -0500 Received: from web80605.mail.yahoo.com ([66.218.79.94]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GptqN-0006WO-7t for pana@ietf.org; Thu, 30 Nov 2006 16:53:28 -0500 Received: (qmail 84123 invoked by uid 60001); 30 Nov 2006 21:53:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=MTpfLLMncOHRvNc4a5gilPrliJK3Sz8u6qXxCV9kKbveWXENN63w9pb6HZvdL6CK1JuyZVIRy1VAzj5BP13I34uYRM7rprviAsK92BJxAFtiQcu4znhAAyeT/vDW+/qPQyMRbixP8LlkKaEGjHtvDyZ8+wO2POI3O5NUzQf+Vo4= ; Message-ID: <20061130215320.84121.qmail@web80605.mail.yahoo.com> Received: from [206.132.194.2] by web80605.mail.yahoo.com via HTTP; Thu, 30 Nov 2006 13:53:20 PST Date: Thu, 30 Nov 2006 13:53:20 -0800 (PST) From: Mohan Parthasarathy Subject: Re: [Pana] Re: review pana spec To: Yoshihiro Ohba MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: yohba@tari.toshiba.com, pana@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Yoshi,=0A=0AInline..=0A=0A> =0A> the draft looks pretty good. I mainly wen= t through the differences. Here are my comments. =0A> =0A> - Abstract calls= it "link-layer" agnostic where as in the Introduction, there is=0A> "min= imum" link-layer dependency. Having gone through this discussion many=0A> = times it might be better to remove both these terms to avoid lengthy discu= ssions :-)=0A=0AFor Abstract, we can replace "link-layer agnostic transport= " with =0A"network layer transport". For Introduction we can remove =0A"mi= nimum link-layer dependency".=0A=0Amohan> That sounds good.=0A=0A =0A=0A> -= Section 5.6 " Pac Updating its IP addresses" : Is this needed for basic ope= ration of PANA ?=0A> The example given in the section makes me believe tha= t it is not required. But it is required=0A> depending on what IP address = you start with. Hence, some clarification is required.=0A=0APerhaps what we= need to say is that PaC needs to update its IP address=0A*used for PANA*. = (We don't need to say which IP address is used for=0APANA, which may be de= scribed by deployment-specific PANA applicability=0Adocuments.)=0A=0AHere i= s revised text for Section 5.6 (also reflecting Alper's=0Acomment):=0A=0A"= =0A5.6. PaC Updating its IP Address=0A=0A A PaC's IP address used for PA= NA can change in certain situations,=0A e.g., when the PaC moves from one= IP link to another within the=0A same PAA's realm. In order to maintain= the PANA session, the PAA=0A needs to be notified about the change of Pa= C address. In order to=0A maintain the PANA session, the PAA needs to be= notified about the=0A change of the IP address of the PaC.=0A=0A After= the PaC has changed its IP address used for PANA, it MUST=0A send a PANA= -Update-Request message to the PAA. The PAA MUST update=0A the PANA sess= ion with the new PaC address carried in the Source=0A Address field of th= e IP header and return a PANA-Update-Answer=0A message. If there is an e= stablished PANA SA, both=0A PANA-Update-Request and PANA-Update-Answer me= ssages MUST be=0A protected with an AUTH AVP.=0A"=0A=0Amohan> It is still= confusing because it is still not clear whether it is required when=0Athe = PaC is not moving (which is the basic operation). At least refer to PANA f= ramework=0Adocument here.=0A=0A=0ARest are fine.=0A=0A-mohan=0A=0A=0A=0A _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Thu Nov 30 20:40:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpxNS-000783-WA; Thu, 30 Nov 2006 20:39:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpxNS-00077r-4h for pana@ietf.org; Thu, 30 Nov 2006 20:39:46 -0500 Received: from inet-tsb5.toshiba.co.jp ([202.33.96.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpxNQ-0005k1-Gc for pana@ietf.org; Thu, 30 Nov 2006 20:39:46 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb5.toshiba.co.jp with ESMTP id kB11deMg005753; Fri, 1 Dec 2006 10:39:40 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id kB11deH6028015; Fri, 1 Dec 2006 10:39:40 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with ESMTP id LAA28013; Fri, 1 Dec 2006 10:39:40 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id kB11denM008629; Fri, 1 Dec 2006 10:39:40 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id kB11bB42020896; Fri, 1 Dec 2006 10:39:34 +0900 (JST) Received: from steelhead ([172.30.24.105]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J9K00ACJN9I6X60@mail.po.toshiba.co.jp>; Fri, 01 Dec 2006 10:39:21 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.63) (envelope-from ) id 1GpxMz-00069z-6u; Thu, 30 Nov 2006 17:39:17 -0800 Date: Thu, 30 Nov 2006 20:39:17 -0500 From: Yoshihiro Ohba Subject: Re: [Pana] Re: review pana spec In-reply-to: <20061130215320.84121.qmail@web80605.mail.yahoo.com> To: Mohan Parthasarathy Message-id: <20061201013917.GK10356@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <20061130215320.84121.qmail@web80605.mail.yahoo.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Yoshihiro Ohba , pana@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Mohan, On Thu, Nov 30, 2006 at 01:53:20PM -0800, Mohan Parthasarathy wrote: (snip) > > Here is revised text for Section 5.6 (also reflecting Alper's > comment): > > " > 5.6. PaC Updating its IP Address > > A PaC's IP address used for PANA can change in certain situations, > e.g., when the PaC moves from one IP link to another within the > same PAA's realm. In order to maintain the PANA session, the PAA > needs to be notified about the change of PaC address. In order to > maintain the PANA session, the PAA needs to be notified about the > change of the IP address of the PaC. > > After the PaC has changed its IP address used for PANA, it MUST > send a PANA-Update-Request message to the PAA. The PAA MUST update > the PANA session with the new PaC address carried in the Source > Address field of the IP header and return a PANA-Update-Answer > message. If there is an established PANA SA, both > PANA-Update-Request and PANA-Update-Answer messages MUST be > protected with an AUTH AVP. > " > > mohan> It is still confusing because it is still not clear whether it is required when > the PaC is not moving (which is the basic operation). At least refer to PANA framework > document here. The PaC is considered as moving if an IP address used for PANA changes but the same PAA is discovered (note PAA discovery is outside the scope of PANA). Isn't the first paragraph clear about that? BTW, PANA framework does not discuss IP address configuration stuff any more, so referring to PANA framework does not help. Regards, Yoshihiro Ohba > > > Rest are fine. > > -mohan > > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Thu Nov 30 20:52:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpxZL-0007Ym-2C; Thu, 30 Nov 2006 20:52:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpxZJ-0007YJ-Sh for pana@ietf.org; Thu, 30 Nov 2006 20:52:01 -0500 Received: from web80605.mail.yahoo.com ([66.218.79.94]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GpxZE-0007YP-GI for pana@ietf.org; Thu, 30 Nov 2006 20:52:01 -0500 Received: (qmail 81486 invoked by uid 60001); 1 Dec 2006 01:51:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=CcfbIPFuZYSR3e31IQN9mr7+aV8wQRpugawVv21DuB1twUDBcHKzOAh24JxVeiLLBDku/SNw8l+v4SkxuCQLxdfoPtUqSObB77AzD2wK7jXIHyvWiTsUat6fFEH58Z2ru5laO5je0gQAo86LrgSppQAH9J4lYmHBwaXAdBQprco= ; Message-ID: <20061201015155.81484.qmail@web80605.mail.yahoo.com> Received: from [206.132.194.3] by web80605.mail.yahoo.com via HTTP; Thu, 30 Nov 2006 17:51:55 PST Date: Thu, 30 Nov 2006 17:51:55 -0800 (PST) From: Mohan Parthasarathy Subject: Re: [Pana] Re: review pana spec To: Yoshihiro Ohba MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Yoshihiro Ohba , pana@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org =0A> Here is revised text for Section 5.6 (also reflecting Alper's=0A> comm= ent):=0A> =0A> "=0A> 5.6. PaC Updating its IP Address=0A> =0A> A PaC's = IP address used for PANA can change in certain situations,=0A> e.g., whe= n the PaC moves from one IP link to another within the=0A> same PAA's re= alm. In order to maintain the PANA session, the PAA=0A> needs to be not= ified about the change of PaC address. In order to=0A> maintain the PAN= A session, the PAA needs to be notified about the=0A> change of the IP a= ddress of the PaC.=0A> =0A> After the PaC has changed its IP address use= d for PANA, it MUST=0A> send a PANA-Update-Request message to the PAA. = The PAA MUST update=0A> the PANA session with the new PaC address carrie= d in the Source=0A> Address field of the IP header and return a PANA-Upd= ate-Answer=0A> message. If there is an established PANA SA, both=0A> = PANA-Update-Request and PANA-Update-Answer messages MUST be=0A> protect= ed with an AUTH AVP.=0A> "=0A> =0A> mohan> It is still confusing because it= is still not clear whether it is required when=0A> the PaC is not moving (= which is the basic operation). At least refer to PANA framework=0A> docume= nt here.=0A=0AThe PaC is considered as moving if an IP address used for PAN= A changes=0Abut the same PAA is discovered (note PAA discovery is outside t= he=0Ascope of PANA). Isn't the first paragraph clear about that? =0A=0Amo= han> Sure. So, are you saying that this is not needed if PaC is not moving.= =0Amohan> I thought it is required in cases where PaC changes its address= =0Amohan> from a link-local to global. These are still allowed, right ?=0A= =0A=0ABTW, PANA framework does not discuss IP address configuration stuff= =0Aany more, so referring to PANA framework does not help.=0A=0Amohan> Inte= resting. Where will it be defined ?=0A=0ARegards,=0AYoshihiro Ohba=0A=0A=0A= =0A> =0A> =0A> Rest are fine.=0A> =0A> -mohan=0A> =0A> =0A> =0A> =0A> =0A> = _______________________________________________=0A> Pana mailing list=0A> P= ana@ietf.org=0A> https://www1.ietf.org/mailman/listinfo/pana=0A> =0A> =0A= =0A=0A _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Thu Nov 30 21:16:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpxwj-0003nX-Mi; Thu, 30 Nov 2006 21:16:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpxwj-0003n4-6m for pana@ietf.org; Thu, 30 Nov 2006 21:16:13 -0500 Received: from imx12.toshiba.co.jp ([61.202.160.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpxwg-0003vZ-IS for pana@ietf.org; Thu, 30 Nov 2006 21:16:13 -0500 Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx12.toshiba.co.jp with ESMTP id kB12G873027233; Fri, 1 Dec 2006 11:16:08 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id kB12G7fO005923; Fri, 1 Dec 2006 11:16:07 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with ESMTP id MAA05918; Fri, 1 Dec 2006 11:16:07 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id kB12G6ZI025205; Fri, 1 Dec 2006 11:16:07 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id kB12G6ub005822; Fri, 1 Dec 2006 11:16:06 +0900 (JST) Received: from steelhead ([172.30.24.105]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J9K00ALCOYP6Z70@mail.po.toshiba.co.jp>; Fri, 01 Dec 2006 11:16:06 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.63) (envelope-from ) id 1GpxwT-0006NN-G3; Thu, 30 Nov 2006 18:15:57 -0800 Date: Thu, 30 Nov 2006 21:15:57 -0500 From: Yoshihiro Ohba Subject: Re: [Pana] Re: review pana spec In-reply-to: <20061201015155.81484.qmail@web80605.mail.yahoo.com> To: Mohan Parthasarathy Message-id: <20061201021557.GA24026@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <20061201015155.81484.qmail@web80605.mail.yahoo.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Yoshihiro Ohba , pana@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org On Thu, Nov 30, 2006 at 05:51:55PM -0800, Mohan Parthasarathy wrote: (snip) > > mohan> Sure. So, are you saying that this is not needed if PaC is not moving > mohan> I thought it is required in cases where PaC changes its address > mohan> from a link-local to global. These are still allowed, right ? I see what you mean. Moving scenario is just one case for IP address change. Sure, a link-local to global transition could be another case. > > > BTW, PANA framework does not discuss IP address configuration stuff > any more, so referring to PANA framework does not help. > > mohan> Interesting. Where will it be defined ? This may be covered by deployment-specific PANA applicability documents. Said that, how about revising the section as follows? " 5.6. PaC Updating its IP Address A PaC's IP address used for PANA can change in certain situations, e.g., when the PaC moves from one IP link to another within the same PAA's realm. Other situations may be described in deployment- specific PANA applicability documents. In order to maintain the PANA session, the PAA needs to be notified about the change of PaC address. In order to maintain the PANA session, the PAA needs to be notified about the change of the IP address of the PaC. After the PaC has changed its IP address used for PANA, it MUST send a PANA-Update-Request message to the PAA. The PAA MUST update the PANA session with the new PaC address carried in the Source Address field of the IP header and return a PANA-Update-Answer message. If there is an established PANA SA, both PANA-Update-Request and PANA-Update-Answer messages MUST be protected with an AUTH AVP. " Regards, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Thu Nov 30 21:29:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpy8v-0000rJ-0F; Thu, 30 Nov 2006 21:28:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpy8u-0000r8-Hk for pana@ietf.org; Thu, 30 Nov 2006 21:28:48 -0500 Received: from web80605.mail.yahoo.com ([66.218.79.94]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gpy8t-0006Va-68 for pana@ietf.org; Thu, 30 Nov 2006 21:28:48 -0500 Received: (qmail 96180 invoked by uid 60001); 1 Dec 2006 02:28:46 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=us+3aohAep96eZU/W3QPXgeMDYMS/0rv/sNXXB30ZsHZu4HVaQHsBrnXZhQ6EK5Q6vxGKCs2RkGPZ7HvxqIRuL72PUaZlTa6NoXaCjhyoU1shiQvXgXQtvFDM3REo4EohP9Mjex/P1+xoDCN8IK7XZGmc6hkvmWe2qvixq3+J5w= ; Message-ID: <20061201022846.96178.qmail@web80605.mail.yahoo.com> Received: from [206.132.194.3] by web80605.mail.yahoo.com via HTTP; Thu, 30 Nov 2006 18:28:46 PST Date: Thu, 30 Nov 2006 18:28:46 -0800 (PST) From: Mohan Parthasarathy Subject: Re: [Pana] Re: review pana spec To: Yoshihiro Ohba MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Yoshihiro Ohba , pana@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Sounds good.=0A=0A-mohan=0A=0A=0A----- Original Message ----=0AFrom: Yoshih= iro Ohba =0ATo: Mohan Parthasarathy =0ACc: Yoshihiro Ohba ; pana@ietf.org=0ASent= : Thursday, November 30, 2006 6:15:57 PM=0ASubject: Re: [Pana] Re: review p= ana spec=0A=0AOn Thu, Nov 30, 2006 at 05:51:55PM -0800, Mohan Parthasarathy= wrote:=0A=0A(snip)=0A=0A> =0A> mohan> Sure. So, are you saying that this i= s not needed if PaC is not moving=0A=0A> mohan> I thought it is required in= cases where PaC changes its address=0A> mohan> from a link-local to global= . These are still allowed, right ?=0A=0AI see what you mean. Moving scenar= io is just one case for IP address=0Achange. Sure, a link-local to global = transition could be another=0Acase.=0A=0A> =0A> =0A> BTW, PANA framework do= es not discuss IP address configuration stuff=0A> any more, so referring to= PANA framework does not help.=0A> =0A> mohan> Interesting. Where will it b= e defined ?=0A=0AThis may be covered by deployment-specific PANA applicabil= ity=0Adocuments. Said that, how about revising the section as follows?=0A= =0A"=0A5.6. PaC Updating its IP Address=0A=0A A PaC's IP address used fo= r PANA can change in certain situations,=0A e.g., when the PaC moves from= one IP link to another within the=0A same PAA's realm. Other situations= may be described in deployment-=0A specific PANA applicability documents= . In order to maintain the=0A PANA session, the PAA needs to be notified= about the change of PaC=0A address. In order to maintain the PANA sessi= on, the PAA needs to=0A be notified about the change of the IP address of= the PaC.=0A=0A After the PaC has changed its IP address used for PANA, i= t MUST=0A send a PANA-Update-Request message to the PAA. The PAA MUST up= date=0A the PANA session with the new PaC address carried in the Source= =0A Address field of the IP header and return a PANA-Update-Answer=0A m= essage. If there is an established PANA SA, both=0A PANA-Update-Request = and PANA-Update-Answer messages MUST be=0A protected with an AUTH AVP.=0A= "=0A=0ARegards,=0AYoshihiro Ohba=0A=0A=0A=0A _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Thu Nov 30 22:36:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpzBz-0006CL-NI; Thu, 30 Nov 2006 22:36:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpzBy-00064z-8a for pana@ietf.org; Thu, 30 Nov 2006 22:36:02 -0500 Received: from inet-tsb5.toshiba.co.jp ([202.33.96.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpzBw-0006PW-L1 for pana@ietf.org; Thu, 30 Nov 2006 22:36:02 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb5.toshiba.co.jp with ESMTP id kB13Zb2x019034; Fri, 1 Dec 2006 12:35:37 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id kB13Zbpd028517; Fri, 1 Dec 2006 12:35:37 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with ESMTP id NAA28516; Fri, 1 Dec 2006 12:35:37 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id kB13ZbR6016859; Fri, 1 Dec 2006 12:35:37 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id kB13ZYc5018719; Fri, 1 Dec 2006 12:35:34 +0900 (JST) Received: from steelhead ([172.30.24.105]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J9K00AHZSN77C90@mail.po.toshiba.co.jp>; Fri, 01 Dec 2006 12:35:34 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.63) (envelope-from ) id 1GpzBS-0006u8-85; Thu, 30 Nov 2006 19:35:30 -0800 Date: Thu, 30 Nov 2006 22:35:30 -0500 From: Yoshihiro Ohba Subject: Re: [Pana] Preliminary pana-pana draft (13a) In-reply-to: <456B7C84.2050204@tari.toshiba.com> To: Victor Fajardo Message-id: <20061201033530.GA25201@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <0MKp2t-1GmXZL49QR-0003s9@mrelay.perfora.net> <456B7C84.2050204@tari.toshiba.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: 'Yoshihiro Ohba' , pana@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org On Mon, Nov 27, 2006 at 07:02:12PM -0500, Victor Fajardo wrote: (snip) > > * Sec 8.5. Failed-Message-Header AVP, 1st Paragraph, 1st sentence > > "The Failed-Message-Header AVP (AVP Code 5) provides debugging > information in cases where a request is rejected or not fully > processed due to erroneous information in a specific AVP. .." > > Editorial. Maybe it the text meant ... > > "The Failed-Message-Header AVP (AVP Code 5) provides debugging > information in cases where a message is rejected or not fully > processed due to erroneous information its header." > I found additional minor errors. - Since a PANA-Error-Request may be sent not only in response to a request but also in response to an answer, it should say "message" in stead of "request". The same comment goes to Failed-AVP AVP. - Also, Failed-AVP AVP format needs to be described in stead of referring to RFC 3588 because it uses its own AVP Type (4) value instead of that for Diameter Failed-AVP AVP (279). So here is the new text for Sections 8.4 and 8.5: " 8.4. Failed-AVP AVP The Failed-AVP AVP (AVP Code 4) provides debugging information in cases where a message is rejected or not fully processed due to erroneous information in a specific AVP. The AVP data is of type Grouped. The format of the Failed-AVP AVP using the ABNF grammar defined in [RFC3588] for Grouped AVP is as follows. ::= < AVP Header: 4 > 1* {AVP} In case of a failed grouped AVP, the Failed-AVP contains the whole grouped AVP. In case of a failed AVP inside a grouped AVP, the Failed-AVP contains the single offending AVP. 8.5. Failed-Message-Header AVP The Failed-Message-Header AVP (AVP Code 5) provides debugging information in cases where a message is rejected or not fully processed due to erroneous information in the message. The AVP data is of type OctetString. The AVP data contains the 16-octet header of the message that caused the error. " Regards, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana