From ancp-bounces@ietf.org Mon Apr 02 07:39:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYKsE-0003eH-St; Mon, 02 Apr 2007 07:38:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYKsD-0003al-LD for ancp@ietf.org; Mon, 02 Apr 2007 07:38:57 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYKsC-0005rS-7h for ancp@ietf.org; Mon, 02 Apr 2007 07:38:57 -0400 Received: from gbmail02.netfr.alcatel.fr (gbmail02.netfr.alcatel.fr [155.132.251.26]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l32BcpY9001705 for ; Mon, 2 Apr 2007 13:38:51 +0200 To: ancp@ietf.org X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Matthew.Bocci@alcatel-lucent.co.uk Date: Mon, 2 Apr 2007 12:38:24 +0100 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 04/02/2007 12:38:44 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [ANCP] Draft Prague minutes X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Please find attached the draft minutes form Prague. These have also been uploaded to the IETF 68 procedeings site at: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68 Many thanks to Ric for taking the notes. Please let me know if you have any comments. Regards, Matthew _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Fri Apr 13 01:19:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcEBt-0008Av-IX; Fri, 13 Apr 2007 01:19:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcEBs-00089E-Pv for ancp@ietf.org; Fri, 13 Apr 2007 01:19:20 -0400 Received: from kecgate03.infosysconsulting.com ([220.227.179.21] helo=Kecgate03.infosys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcEBs-00006D-0O for ancp@ietf.org; Fri, 13 Apr 2007 01:19:20 -0400 Received: from indhubbhs04.ad.infosys.com ([192.168.200.84]) by Kecgate03.infosys.com with InterScan Message Security Suite; Fri, 13 Apr 2007 10:48:12 +0530 Received: from BLRKECMSG04.ad.infosys.com ([172.25.213.134]) by indhubbhs04.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 10:48:58 +0530 Received: from BLRKECMSG01.ad.infosys.com ([172.25.213.131]) by BLRKECMSG04.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 10:48:57 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Apr 2007 10:48:55 +0530 Message-ID: <6031539A3C7B964581EFCE2E205D6EEF021E0A43@BLRKECMSG01.ad.infosys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Some comments on ANCP MIB Thread-Index: Acd9iYvvmgxaV9jORsiN4Q7ZaW21gg== From: "bharat_joshi" To: X-OriginalArrivalTime: 13 Apr 2007 05:18:57.0486 (UTC) FILETIME=[3CA71EE0:01C77D8B] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Subject: [ANCP] Some comments on ANCP MIB X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi Stefaan, Couple of questions and suggestion on the MIB document: [I am not sure if this has already been raised before] * In 'Structure of the MIB Module', I think it would be good if the three tables can be defined point wise something similar to the way you have defined groups] There are three tables defined in this MIB module: 1. ancpAnSessionConfigTable is used to configure ANCP sessions. 2. ancpAnCurrentSessionTable is used to show the operational status of an ANCP session. 3. Third table name is not there. * Does all the objects under these tables are mandatory to be implemented by an Access Node? * I think second paragraph of section 5.3 can be moved to Security Consideration. * In section 5.4, We assumed that for each port, there is only one corresponding interface in IF-MIB which does not seems to be correct. There can be multiple interfaces on one port. Also the reference to DSL-Line does not seem to be correct as it would be the upstream interface of AN [Interface towards the NAS] where ANCP would be configured. * As per RFC 4181, 'ancpNotifications' should be 'ancpAnNotifications' * When a session is deleted and the corresponding session-id would be available. Does this mean that the 'get' on object 'ancpAnNextSessionId' will start returning this available value? It is not completely clear from the text. It just says that it will be available. * If there are partitions, there will be one ANCP session corresponding to each partition. Right? * In ancpAnSessionConfigAliveTimer, I think we should use ANCP instead of GSMP in " duration of a GSMP session" -> " duration of a ANCP session" * In ancpAnSessionConfigAliveTimer, please provide an example for default value 100 i.e. add a value of 100 means 100*100 ms. * In description of object ancpAnSessionConfigGsmpRetryTimer, I did not get the meaning of 'Whatever the setting of this timer, the access node shall always listen for ANCP session setup.'. I think Access node triggers the session setup so does it listen for session request as well. * In description of ancpAnCurrentSessionTable, its mentioned that: A row in this table is created when the corresponding row in the ancpAnSessionConfigTable is activated.=20 But there is not active field in ancpAnSessionConfigTable which can activate a row. I think you meant 'created'. * In description ancpAnCurrentSessionAnName, I think we should reword the following line: "It should be the same as ancpAnSessionConfigAnName." In description of ancpAnSessionConfigAnName, we say that if its value is configured as NULL, we use an appropriate MAC address. * I think 'ancpSessionDown' and 'ancpSessionUp' should point to ancpAnCurrentSessionState and description should say that 'ancpSessionUp' will be sent when the value of object 'ancpAnCurrentSessionState' is set to estab(4) and similarly 'ancpSessionDown' will be sent when the value of object 'ancpAnCurrentSessionState' is moved from estab(4) to any other value. * As we have made all the four groups in the mandatory-groups, it means all the devices supporting ANCP to support partitions as well. Do you really think every device that supports ANCP supports partitions? Can not we be a little lenient on this and keep this as recommended? Thanks & Regards, Bharat **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended= solely for the use of the addressee(s). If you are not the intended= recipient, please notify the sender by e-mail and delete the original= message. Further, you are not to copy, disclose, or distribute this e-mail= or its contents to any other person and any such actions are unlawful.= This e-mail may contain viruses. Infosys has taken every reasonable= precaution to minimize this risk, but is not liable for any damage you may= sustain as a result of any virus in this e-mail. You should carry out your= own virus checks before opening the e-mail or attachment. Infosys reserves= the right to monitor and review the content of all messages sent to or= from this e-mail address. Messages sent to or from this e-mail address may= be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Apr 16 04:25:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdMWM-0002A8-SN; Mon, 16 Apr 2007 04:25:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdMWL-0002A0-5P for ancp@ietf.org; Mon, 16 Apr 2007 04:25:09 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdMWH-0003h5-9W for ancp@ietf.org; Mon, 16 Apr 2007 04:25:07 -0400 Received: from bemail06.netfr.alcatel.fr (bemail06.netfr.alcatel.fr [155.132.251.30]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l3G8PAL2014633; Mon, 16 Apr 2007 10:25:10 +0200 Received: from [172.31.131.47] ([172.31.131.47]) by bemail06.netfr.alcatel.fr (Lotus Domino Release 5.0.13aHF163) with ESMTP id 2007041610250247:1788 ; Mon, 16 Apr 2007 10:25:02 +0200 Message-ID: <462332DD.1050704@alcatel-lucent.be> Date: Mon, 16 Apr 2007 10:25:01 +0200 From: stefaan.de_cnodder@alcatel-lucent.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bharat_joshi Subject: Re: [ANCP] Some comments on ANCP MIB References: <6031539A3C7B964581EFCE2E205D6EEF021E0A43@BLRKECMSG01.ad.infosys.com> In-Reply-To: <6031539A3C7B964581EFCE2E205D6EEF021E0A43@BLRKECMSG01.ad.infosys.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 04/16/2007 10:25:02, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 04/16/2007 10:25:03, Serialize complete at 04/16/2007 10:25:03 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi Bharat, Thanks for you comments. See my answers inline... > > * In 'Structure of the MIB Module', I think it would be good if the > three tables can be defined point wise something similar to the way you > have defined groups] > > There are three tables defined in this MIB module: > > 1. ancpAnSessionConfigTable is used to configure ANCP sessions. > > 2. ancpAnCurrentSessionTable is used to show the operational status of > an ANCP session. > > 3. Third table name is not there. > Yes, this would be better. > * Does all the objects under these tables are mandatory to be > implemented by an Access Node? > yes, see compliance statement at the end of the MIB. As far as I can see, none of them can be really made optional altough for some it can be considered. > * I think second paragraph of section 5.3 can be moved to Security > Consideration. > I prefer to keep everything about notifications together. This is also not realy related to security. > * In section 5.4, We assumed that for each port, there is only one > corresponding interface in IF-MIB which does not seems to be correct. > There can be multiple interfaces on one port. Also the reference to > DSL-Line does not seem to be correct as it would be the upstream > interface of AN [Interface towards the NAS] where ANCP would be > configured. > Not sure what you mean here. Suppose that a DSL line has an ifindex, and also the PVCs on the DSL line has ifindexes. In that case, only the ifindex of the DSL line will create a row in the ancpAnInterfaceConfigTable. > * As per RFC 4181, 'ancpNotifications' should be 'ancpAnNotifications' > yes, and also the 2 notifications need to be adapted. > * When a session is deleted and the corresponding session-id would be > available. Does this mean that the 'get' on object 'ancpAnNextSessionId' > will start returning this available value? It is not completely clear > from the text. It just says that it will be available. > that's implementation specific. A get will give an available value but it does not matter which one. Typical implementations will use round robin. > * If there are partitions, there will be one ANCP session corresponding > to each partition. Right? > No, there can be multiple sessions per partition, but a session for the moment can only have one partition. There was some discussion on this in the recent past but there was no clear case where it was useful to have multiple partitions per sessions. For the moment the MIB allows multiple sessions per partitions, and not multiple partitions per session. Maybe the last part should change even if there is not really a good use case for it > * In ancpAnSessionConfigAliveTimer, I think we should use ANCP instead > of GSMP in " duration of a GSMP session" -> " duration of a ANCP > session" > ok > * In ancpAnSessionConfigAliveTimer, please provide an example for > default value 100 i.e. add a value of 100 means 100*100 ms. > This is used quite often and i think it is clear without examples. Adding examples would mean doing this for each case where it occurs. Look to the UNITS clause, that is there to make it clear. > * In description of object ancpAnSessionConfigGsmpRetryTimer, I did not > get the meaning of 'Whatever the setting of this timer, the access node > shall always listen for ANCP session setup.'. I think Access node > triggers the session setup so does it listen for session request as > well. > According to the protocols spec. the AN should set up the session and not the NAS. However, it is somehow strange that when an AN is trying to set up a session, that it would forbid setting up a session from the NAS. > * In description of ancpAnCurrentSessionTable, its mentioned that: > A row in this table is created when the corresponding row > in the ancpAnSessionConfigTable is activated. > > But there is not active field in ancpAnSessionConfigTable which can > activate a row. I think you meant 'created'. > correct > * In description ancpAnCurrentSessionAnName, I think we should reword > the following line: "It should be the same as > ancpAnSessionConfigAnName." In description of ancpAnSessionConfigAnName, > we say that if its value is configured as NULL, we use an appropriate > MAC address. > indeed, this sentence is not really clear > * I think 'ancpSessionDown' and 'ancpSessionUp' should point to > ancpAnCurrentSessionState and description should say that > 'ancpSessionUp' will be sent when the value of object > 'ancpAnCurrentSessionState' is set to estab(4) and similarly > 'ancpSessionDown' will be sent when the value of object > 'ancpAnCurrentSessionState' is moved from estab(4) to any other value. > it is mentioned in the description of the notifications. I think you overlooked this? > * As we have made all the four groups in the mandatory-groups, it means > all the devices supporting ANCP to support partitions as well. Do you > really think every device that supports ANCP supports partitions? Can > not we be a little lenient on this and keep this as recommended? > The requirement is coming from the framework/req document: "... the Access Node MUST support at least 2 partitions...". Therefore it is made mandatory in the MIB as well. regards, Stefaan > Thanks & Regards, > Bharat > > **************** CAUTION - Disclaimer ***************** > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. > ***INFOSYS******** End of Disclaimer ********INFOSYS*** > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Apr 16 06:18:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdOHc-0005sO-LW; Mon, 16 Apr 2007 06:18:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdOHb-0005sJ-HX for ancp@ietf.org; Mon, 16 Apr 2007 06:18:03 -0400 Received: from kecgate03.infosysconsulting.com ([220.227.179.21] helo=Kecgate03.infosys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdOHa-0007eP-OU for ancp@ietf.org; Mon, 16 Apr 2007 06:18:03 -0400 Received: from indhubbhs04.ad.infosys.com ([192.168.200.84]) by Kecgate03.infosys.com with InterScan Message Security Suite; Mon, 16 Apr 2007 15:47:18 +0530 Received: from BLRKECMSG14.ad.infosys.com ([172.22.147.6]) by indhubbhs04.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 15:48:00 +0530 Received: from BLRKECMSG01.ad.infosys.com ([172.25.213.131]) by BLRKECMSG14.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 15:47:59 +0530 Received: from [10.10.10.170] ([192.168.101.134]) by BLRKECMSG01.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 15:47:59 +0530 Subject: Re: [ANCP] Some comments on ANCP MIB From: Bharat Joshi To: stefaan.de_cnodder@alcatel-lucent.be In-Reply-To: <462332DD.1050704@alcatel-lucent.be> References: <6031539A3C7B964581EFCE2E205D6EEF021E0A43@BLRKECMSG01.ad.infosys .com> <462332DD.1050704@alcatel-lucent.be> Content-Type: text/plain Organization: Infosys Technologies Ltd Date: Mon, 16 Apr 2007 15:36:05 +0530 Message-Id: <1176717965.2675.40.camel@magadha> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Apr 2007 10:17:59.0426 (UTC) FILETIME=[821F2620:01C78010] X-Spam-Score: 0.1 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi Stefaan, Please see my response in line. Thanks, Bharat > > * In 'Structure of the MIB Module', I think it would be good if the > > three tables can be defined point wise something similar to the way you > > have defined groups] > > > > There are three tables defined in this MIB module: > > > > 1. ancpAnSessionConfigTable is used to configure ANCP sessions. > > > > 2. ancpAnCurrentSessionTable is used to show the operational status of > > an ANCP session. > > > > 3. Third table name is not there. > > > > Yes, this would be better. > Ok. > > * Does all the objects under these tables are mandatory to be > > implemented by an Access Node? > > > > yes, see compliance statement at the end of the MIB. As far as I can > see, none of them can be really made optional altough for some it can be > considered. > Ok. If they must be implemented than it is fine. > > * I think second paragraph of section 5.3 can be moved to Security > > Consideration. > > > > I prefer to keep everything about notifications together. This is also > not realy related to security. > Ok. I just suggested this because I think it makes more sense under Security Consideration. > > * In section 5.4, We assumed that for each port, there is only one > > corresponding interface in IF-MIB which does not seems to be correct. > > There can be multiple interfaces on one port. Also the reference to > > DSL-Line does not seem to be correct as it would be the upstream > > interface of AN [Interface towards the NAS] where ANCP would be > > configured. > > > > Not sure what you mean here. Suppose that a DSL line has an ifindex, > and also the PVCs on the DSL line has ifindexes. In that case, only the > ifindex of the DSL line will create a row in the ancpAnInterfaceConfigTable. > I understand that there can be one or more interface per DSL link. I am not sure if there are interfaces created for each DSL line separately. If thats the common practice this should be fine. In any case, it would be better if you can add this details here. > > * As per RFC 4181, 'ancpNotifications' should be 'ancpAnNotifications' > > > yes, and also the 2 notifications need to be adapted. > Ok. > > * When a session is deleted and the corresponding session-id would be > > available. Does this mean that the 'get' on object 'ancpAnNextSessionId' > > will start returning this available value? It is not completely clear > > from the text. It just says that it will be available. > > > > that's implementation specific. A get will give an available value but > it does not matter which one. Typical implementations will use round robin. > Ok. > > * If there are partitions, there will be one ANCP session corresponding > > to each partition. Right? > > > > No, there can be multiple sessions per partition, but a session for the > moment can only have one partition. There was some discussion on this > in the recent past but there was no clear case where it was useful to > have multiple partitions per sessions. For the moment the MIB allows > multiple sessions per partitions, and not multiple partitions per > session. Maybe the last part should change even if there is not really > a good use case for it Ok. I think some more text here will surely help. > > * In ancpAnSessionConfigAliveTimer, please provide an example for > > default value 100 i.e. add a value of 100 means 100*100 ms. > > > > This is used quite often and i think it is clear without examples. > Adding examples would mean doing this for each case where it occurs. > Look to the UNITS clause, that is there to make it clear. > Ok. I thought it might be helpful to be more explicit. > > * In description of object ancpAnSessionConfigGsmpRetryTimer, I did not > > get the meaning of 'Whatever the setting of this timer, the access node > > shall always listen for ANCP session setup.'. I think Access node > > triggers the session setup so does it listen for session request as > > well. > > > > According to the protocols spec. the AN should set up the session and > not the NAS. However, it is somehow strange that when an AN is trying > to set up a session, that it would forbid setting up a session from the NAS. > So its AN which triggers the session than what is it listen for as mentioned in the above sentence? > > * In description ancpAnCurrentSessionAnName, I think we should reword > > the following line: "It should be the same as > > ancpAnSessionConfigAnName." In description of ancpAnSessionConfigAnName, > > we say that if its value is configured as NULL, we use an appropriate > > MAC address. > > > > indeed, this sentence is not really clear > Ok. Please make it more readable. > > * I think 'ancpSessionDown' and 'ancpSessionUp' should point to > > ancpAnCurrentSessionState and description should say that > > 'ancpSessionUp' will be sent when the value of object > > 'ancpAnCurrentSessionState' is set to estab(4) and similarly > > 'ancpSessionDown' will be sent when the value of object > > 'ancpAnCurrentSessionState' is moved from estab(4) to any other value. > > > > it is mentioned in the description of the notifications. I think you > overlooked this? > What I meant is that instead of referencing these notifications to the object mentioned in the document, they should be referenced to 'ancpAnCurrentSessionState'. Because this object's value decides whether a Notification should be generated or not. > > * As we have made all the four groups in the mandatory-groups, it means > > all the devices supporting ANCP to support partitions as well. Do you > > really think every device that supports ANCP supports partitions? Can > > not we be a little lenient on this and keep this as recommended? > > > > The requirement is coming from the framework/req document: "... the > Access Node MUST support at least 2 partitions...". Therefore it is > made mandatory in the MIB as well. Ok. Another thing which I have seen MIB Doctors ask for is that the REFERENCE clause for Objects. If an object can be referenced to the protocol/framework document, please add the reference. **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Apr 16 06:36:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdOZ4-0003mF-Ey; Mon, 16 Apr 2007 06:36:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdOZ4-0003mA-34 for ancp@ietf.org; Mon, 16 Apr 2007 06:36:06 -0400 Received: from eci-iron.ecitele.com ([147.234.242.112] helo=iron.ecitele.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HdOZ3-0005qV-3N for ancp@ietf.org; Mon, 16 Apr 2007 06:36:06 -0400 Received: from ilptexfe.ecitele.com (HELO ILPTEXFE01.ecitele.com) ([172.31.244.40]) by iron.ecitele.com with ESMTP; 16 Apr 2007 13:39:50 +0300 Received: from ILPTMAIL01.ecitele.com ([147.234.245.210]) by ILPTEXFE01.ecitele.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 16 Apr 2007 13:35:58 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ANCP] Some comments on ANCP MIB Date: Mon, 16 Apr 2007 13:36:00 +0300 Message-ID: <83153A1EB675AF4F82E134FA27F95F67011537D8@ilptex01.ecitele.com> In-Reply-To: <1176717965.2675.40.camel@magadha> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Some comments on ANCP MIB Thread-Index: AceAEIh19jS+UiCJTtWeYpEkrH2kbwAAFADA References: <6031539A3C7B964581EFCE2E205D6EEF021E0A43@BLRKECMSG01.ad.infosys .com><462332DD.1050704@alcatel-lucent.be> <1176717965.2675.40.camel@magadha> From: "Moti Morgenstern" To: "Bharat Joshi" , X-OriginalArrivalTime: 16 Apr 2007 10:35:58.0435 (UTC) FILETIME=[0542DB30:01C78013] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Cc: ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi, One comment regarding to the "discussion" on section 5.4:=20 There are optionally multiple sub layers over a single DSL line, i.e., multiple bearer channels, multiple ATM VPs and VCs, etc. However, only the bearer channels and the DSL line itself have ifIndex patterns (each has a different IfType value, which makes it easier to determine whether or not it requires a row in the ancpAnInterfaceConfigTable). The ATM entities (VPs and VCs) do not have ifIndex ! They are all associated with the ifIndex of the ATM interface (The ATM interface may have a 1:1 relationship with either a bearer channel or the whole DSL line).=20 Regards, Moti Morgenstern =20 Senior Systems Engineer ECI Telecom Ltd. Broadband Access Division 30 Hasivim St. Petach Tikva, Israel 49517 Tel.: +972-3-9266258 Fax.: +972-3-9287342=20 Cell.: +972-54-5786258 e-mail: Moti.Morgenstern@ecitele.com =20 -----Original Message----- From: Bharat Joshi [mailto:bharat_joshi@infosys.com]=20 Sent: Monday, April 16, 2007 1:06 PM To: stefaan.de_cnodder@alcatel-lucent.be Cc: ancp@ietf.org Subject: Re: [ANCP] Some comments on ANCP MIB Hi Stefaan, Please see my response in line. Thanks, Bharat > > * In 'Structure of the MIB Module', I think it would be good if the > > three tables can be defined point wise something similar to the way you > > have defined groups] > >=20 > > There are three tables defined in this MIB module: > >=20 > > 1. ancpAnSessionConfigTable is used to configure ANCP sessions. > >=20 > > 2. ancpAnCurrentSessionTable is used to show the operational status of > > an ANCP session. > >=20 > > 3. Third table name is not there. > >=20 >=20 > Yes, this would be better. >=20 Ok. > > * Does all the objects under these tables are mandatory to be > > implemented by an Access Node? > >=20 >=20 > yes, see compliance statement at the end of the MIB. As far as I can=20 > see, none of them can be really made optional altough for some it can be=20 > considered. >=20 Ok. If they must be implemented than it is fine. > > * I think second paragraph of section 5.3 can be moved to Security > > Consideration. > >=20 >=20 > I prefer to keep everything about notifications together. This is also=20 > not realy related to security. >=20 Ok. I just suggested this because I think it makes more sense under Security Consideration. > > * In section 5.4, We assumed that for each port, there is only one > > corresponding interface in IF-MIB which does not seems to be correct. > > There can be multiple interfaces on one port. Also the reference to > > DSL-Line does not seem to be correct as it would be the upstream > > interface of AN [Interface towards the NAS] where ANCP would be > > configured. > >=20 >=20 > Not sure what you mean here. Suppose that a DSL line has an ifindex,=20 > and also the PVCs on the DSL line has ifindexes. In that case, only the=20 > ifindex of the DSL line will create a row in the ancpAnInterfaceConfigTable. >=20 I understand that there can be one or more interface per DSL link. I am not sure if there are interfaces created for each DSL line separately. If thats the common practice this should be fine. In any case, it would be better if you can add this details here. > > * As per RFC 4181, 'ancpNotifications' should be 'ancpAnNotifications' > >=20 > yes, and also the 2 notifications need to be adapted. >=20 Ok. > > * When a session is deleted and the corresponding session-id would be > > available. Does this mean that the 'get' on object 'ancpAnNextSessionId' > > will start returning this available value? It is not completely clear > > from the text. It just says that it will be available. > >=20 >=20 > that's implementation specific. A get will give an available value but=20 > it does not matter which one. Typical implementations will use round robin. >=20 Ok. > > * If there are partitions, there will be one ANCP session corresponding > > to each partition. Right? > >=20 >=20 > No, there can be multiple sessions per partition, but a session for the=20 > moment can only have one partition. There was some discussion on this > in the recent past but there was no clear case where it was useful to=20 > have multiple partitions per sessions. For the moment the MIB allows=20 > multiple sessions per partitions, and not multiple partitions per=20 > session. Maybe the last part should change even if there is not really=20 > a good use case for it Ok. I think some more text here will surely help. > > * In ancpAnSessionConfigAliveTimer, please provide an example for > > default value 100 i.e. add a value of 100 means 100*100 ms. > >=20 >=20 > This is used quite often and i think it is clear without examples.=20 > Adding examples would mean doing this for each case where it occurs.=20 > Look to the UNITS clause, that is there to make it clear. >=20 Ok. I thought it might be helpful to be more explicit. > > * In description of object ancpAnSessionConfigGsmpRetryTimer, I did not > > get the meaning of 'Whatever the setting of this timer, the access node > > shall always listen for ANCP session setup.'. I think Access node > > triggers the session setup so does it listen for session request as > > well. > >=20 >=20 > According to the protocols spec. the AN should set up the session and=20 > not the NAS. However, it is somehow strange that when an AN is trying > to set up a session, that it would forbid setting up a session from the NAS. >=20 So its AN which triggers the session than what is it listen for as mentioned in the above sentence? > > * In description ancpAnCurrentSessionAnName, I think we should reword > > the following line: "It should be the same as > > ancpAnSessionConfigAnName." In description of ancpAnSessionConfigAnName, > > we say that if its value is configured as NULL, we use an appropriate > > MAC address. > >=20 >=20 > indeed, this sentence is not really clear >=20 Ok. Please make it more readable. > > * I think 'ancpSessionDown' and 'ancpSessionUp' should point to > > ancpAnCurrentSessionState and description should say that > > 'ancpSessionUp' will be sent when the value of object > > 'ancpAnCurrentSessionState' is set to estab(4) and similarly > > 'ancpSessionDown' will be sent when the value of object > > 'ancpAnCurrentSessionState' is moved from estab(4) to any other value. > >=20 >=20 > it is mentioned in the description of the notifications. I think you=20 > overlooked this? >=20 What I meant is that instead of referencing these notifications to the object mentioned in the document, they should be referenced to 'ancpAnCurrentSessionState'. Because this object's value decides whether a Notification should be generated or not. > > * As we have made all the four groups in the mandatory-groups, it means > > all the devices supporting ANCP to support partitions as well. Do you > > really think every device that supports ANCP supports partitions? Can > > not we be a little lenient on this and keep this as recommended? > >=20 >=20 > The requirement is coming from the framework/req document: "... the=20 > Access Node MUST support at least 2 partitions...". Therefore it is=20 > made mandatory in the MIB as well. Ok. Another thing which I have seen MIB Doctors ask for is that the REFERENCE clause for Objects. If an object can be referenced to the protocol/framework document, please add the reference. **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Apr 18 04:34:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He5c8-0006oI-9x; Wed, 18 Apr 2007 04:34:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He5c7-0006lT-5Y for ancp@ietf.org; Wed, 18 Apr 2007 04:34:07 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He5c5-0005DD-Kx for ancp@ietf.org; Wed, 18 Apr 2007 04:34:07 -0400 Received: from bemail06.netfr.alcatel.fr (bemail06.netfr.alcatel.fr [155.132.251.30]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l3I8YA5L021887; Wed, 18 Apr 2007 10:34:10 +0200 Received: from [172.31.131.47] ([172.31.131.47]) by bemail06.netfr.alcatel.fr (Lotus Domino Release 5.0.13aHF163) with ESMTP id 2007041810340313:2343 ; Wed, 18 Apr 2007 10:34:03 +0200 Message-ID: <4625D7FB.8070905@alcatel-lucent.be> Date: Wed, 18 Apr 2007 10:34:03 +0200 From: stefaan.de_cnodder@alcatel-lucent.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bharat Joshi Subject: Re: [ANCP] Some comments on ANCP MIB References: <6031539A3C7B964581EFCE2E205D6EEF021E0A43@BLRKECMSG01.ad.infosys .com> <462332DD.1050704@alcatel-lucent.be> <1176717965.2675.40.camel@magadha> In-Reply-To: <1176717965.2675.40.camel@magadha> X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 04/18/2007 10:34:03, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 04/18/2007 10:34:04, Serialize complete at 04/18/2007 10:34:04 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi Bharat, see more inline... > > >>>* In description of object ancpAnSessionConfigGsmpRetryTimer, I did not >>>get the meaning of 'Whatever the setting of this timer, the access node >>>shall always listen for ANCP session setup.'. I think Access node >>>triggers the session setup so does it listen for session request as >>>well. >>> >> >>According to the protocols spec. the AN should set up the session and >>not the NAS. However, it is somehow strange that when an AN is trying >>to set up a session, that it would forbid setting up a session from the NAS. >> > > > So its AN which triggers the session than what is it listen for as > mentioned in the above sentence? > It is strictly not forbidden for the NAS to set up a session so there is no reason why the AN should reject that. From a protocol point of view it would be strange that if a device tries to setup an adjacency that it would reject a setup attempt from the other side. There is no NAS MIB but if there would be one, then I guess that in that MIB, there would be a similar table as the sessionconfig table in the AN MIB but it would be an optional table and not a mandatory table as it is for the AN. Though I do not really have as strong opinion about this, and whatever looks fine to me. > > >>>* I think 'ancpSessionDown' and 'ancpSessionUp' should point to >>>ancpAnCurrentSessionState and description should say that >>>'ancpSessionUp' will be sent when the value of object >>>'ancpAnCurrentSessionState' is set to estab(4) and similarly >>>'ancpSessionDown' will be sent when the value of object >>>'ancpAnCurrentSessionState' is moved from estab(4) to any other value. >>> >> >>it is mentioned in the description of the notifications. I think you >>overlooked this? >> > > > What I meant is that instead of referencing these notifications to the > object mentioned in the document, they should be referenced to > 'ancpAnCurrentSessionState'. Because this object's value decides whether > a Notification should be generated or not. > the value of the ancpAnCurrentSessionState is implicit from the notification: if case of session up it will always be estab(4) so no reason to give this in the notification. Similar for down: it will not be estab(4) anymore. The list of objects in the notifications is already large, so I prefer to reduce as much as possible. Thanks, Stefaan > >>>* As we have made all the four groups in the mandatory-groups, it means >>>all the devices supporting ANCP to support partitions as well. Do you >>>really think every device that supports ANCP supports partitions? Can >>>not we be a little lenient on this and keep this as recommended? >>> >> >>The requirement is coming from the framework/req document: "... the >>Access Node MUST support at least 2 partitions...". Therefore it is >>made mandatory in the MIB as well. > > > Ok. > > Another thing which I have seen MIB Doctors ask for is that the > REFERENCE clause for Objects. If an object can be referenced to the > protocol/framework document, please add the reference. > > > **************** CAUTION - Disclaimer ***************** > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. > ***INFOSYS******** End of Disclaimer ********INFOSYS*** _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Apr 23 07:23:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfwdj-0005tg-2l; Mon, 23 Apr 2007 07:23:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfwdi-0005r7-Bl for ancp@ietf.org; Mon, 23 Apr 2007 07:23:26 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hfwdg-00058t-TE for ancp@ietf.org; Mon, 23 Apr 2007 07:23:26 -0400 Received: from gbmail02.netfr.alcatel.fr (gbmail02.netfr.alcatel.fr [155.132.251.26]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l3NBNRqb032014; Mon, 23 Apr 2007 13:23:27 +0200 In-Reply-To: <005601c76fdb$3f45d2d0$4201a8c0@ad.redback.com> Subject: RE: [ANCP] ANCP AN MIB to WG draft? To: moti.Morgenstern@ecitele.com, stefaan.de_cnodder@alcatel-lucent.be X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Matthew.Bocci@alcatel-lucent.co.uk Date: Mon, 23 Apr 2007 12:13:35 +0100 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 04/23/2007 12:23:21 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Stefaan, Moti, Please upload the next version of this draft as a ANCP WG document. Regards, Matthew "Curtis Sherbo" To 26/03/2007 20:16 cc Subject RE: [ANCP] ANCP AN MIB to WG draft? I support this becoming a WG Draft. Thanks, Curtis -----Original Message----- From: Matthew.Bocci@alcatel-lucent.co.uk [mailto:Matthew.Bocci@alcatel-lucent.co.uk] Sent: Wednesday, March 21, 2007 4:43 AM To: ancp@ietf.org Subject: [ANCP] ANCP AN MIB to WG draft? During the meeting in Prague, there was a request to make draft-decnodder-ancp-mib-an-01.txt a working group draft. Please indicate to the list if you support this. Regards, Matthew _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp