Subject: Re: [Adslmib] Vector of Profiles MIB

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 1 Dec 2009 11:03:54 +0100

Does this mean that you suggest that the extension we are talking about should also cover these? 

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Tuesday, December 01, 2009 9:38 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Adslmib] Vector of Profiles MIB
> 
> Menachem,
>  
> According point no. 1 in your email I want to add a minor 
> comment: TR-165 deals also with adsl, adsl2 and adsl2plus and 
> not only vdsl2.  
> 
> Markus
> 
> -----Ursprüngliche Nachricht-----
> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von Freudenberger, Markus
> Gesendet: Montag, 30. November 2009 22:43
> An: [email-masked]
> Cc: [email-masked]; [email-masked]
> Betreff: Re: [Adslmib] Vector of Profiles MIB
> 
> 
>  Hello Menachem,
> 
> I agree with your proposal.
> 
> Regards
> Markus
>  
> 
> -----Ursprüngliche Nachricht-----
> Von: Menachem Dodge [mailto:[email-masked]]
> Gesendet: Sonntag, 29. November 2009 16:26
> An: [email-masked]; [email-masked]; 'Scott 
> Baillie'; Moti Morgenstern; Freudenberger, Markus
> Cc: [email-masked]
> Betreff: RE: [Adslmib] Vector of Profiles MIB
> 
> Hello All,
> 
> Although only a small number of WG members have been involved 
> in this discussion, there has nonetheless been strong 
> differences of opinion.
> 
> However, I would like to see if a consensus can be reached 
> based on suggestions already put forward.
> 
> Can we agree on the following:
> 
> 	1. The WG develops an additional optional Vdsl2 
> configuration extension MIB based on TR-165. 
> 	   	a. This extension contains a "scalar variable" 
> or "switch" used by the manager and the SNMP agent to negotiate 
>                whether VDSL2 configuration will be done by 
> the TR-165 VoP Method or the TR-129 RFC 5650 Method. 
> 	      b. The default of the "scalar variable" is TR-129 
> RFC 5650 Method. 
> 	      c. If either the SNMP manager or the SNMP Agent 
> do not support the extension MIB and hence the "switch", 
>                configuration will be done by TR-129 RFC 5650.
> 	2. RFC 5650 remains unchanged. 
> 	3. Support of RFC 5650 is mandatory.
> 	
> Please indicate agreement or disagreement to the above.
> 
> Thank you kindly,
> Menachem
> 	
> 
> 
> -----Original Message-----
> From: peidaoyu [mailto:[email-masked]]
> Sent: Tuesday, November 24, 2009 3:30 PM
> To: [email-masked]; 'Scott Baillie'; Menachem Dodge
> Cc: [email-masked]
> Subject: 答复: [Adslmib] Vector of Profiles MIB
> 
> Hi all,
> I don't think that 10-100 profiles are enough for used to 
> manage order of
> 10^5 to 10^6 xDSL lines, maybe it's enough for adsl, but it’s 
> not enough for vdsl2. Furthermore, the memory is not the only 
> reason to define TR165.
> In FTTx or DLM or DSM cases the TR165 model is more suitable, 
> it makes configuration simpler. 
> As there are two many differences between these two models, 
> the translation between TR-129 model and TR-165 model is 
> almost impossible, and makes no sense. Maybe a switch is 
> suitable, then it up to the operator to choose a management 
> model it prefers to.
> Regards,
> PeiDaoyu
> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表
> Umberto Bonollo
> 发送时间: 2009年11月24日 15:01
> 收件人: 'Scott Baillie'; Menachem Dodge
> 抄送: [email-masked]
> 主题: Re: [Adslmib] Vector of Profiles MIB
> 
> Hi Scott,
> I am in agreement with your position in 1. and 2. below.
> It must be possible for RFC-5650 to work independently of 
> possible optional VOP add-on.
> From very large projects in the field I'm aware of, 
> typically,  10-100 profiles are used to manage order of 10^5 
> to 10^6 xDSL lines.
> 
> Regards,
> Umberto Bonollo
> RFC-5650 co-author
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Scott Baillie
> Sent: Tuesday, 24 November 2009 3:43 PM
> To: Menachem Dodge
> Cc: [email-masked]
> Subject: Re: [Adslmib] Vector of Profiles MIB
> 
> 
> Hi All,
> 
> I would like to summarise my position on the Vector of 
> Profiles MIB proposal so that it is clearer what my position 
> is, but I would like to hear the views of the group on these issues.
> 
> My position
> -----------
> 1. I would prefer that the TR-165 enhancements be implemented
>    at a lower layer and hence no need to change the RFC-5650
>    management interface. The reasons for this are covered
>    in my previous post.
> 2. If the RFC-5650 extension MIB was to go ahead anyway,
>    I would be very much opposed to the effort unless :
>    a) The TR-129 model is mandatory and the TR-165 model is
>       optional. Hence, a SNMP agent MUST implement the template
>       model but MAY implement the VoP model.
>    b) The tables in RFC-5650 are not altered in any way, only
>       one scalar variable is added to RFC-5650. The scalar
>       variable would be writeable and have 2 values.
>    c) When a SNMP agent is configured to operate in TR-165
>       mode, it must also be fully manageable by a SNMP
>       manager that only understands the TR-129 model.
> 
> Regards,
> 
> Scott.
> 
> On Mon, 2009-11-23 at 17:21 +0200, Menachem Dodge wrote:
> > Hello,
> > 
> > So far only a small number of WG members have offered their 
> opinion as 
> > to
> whether or not the TR-165 management model should be developed.
> > 
> > A suggestion has been proposed such that an optional 
> extension to RFC 
> > 5650
> be developed that would contain a switch allowing either the 
> current TR-129 model or the TR-165 model to be supported.
> > 
> > The opinions thus far have been divided, even regarding 
> this optional
> extension.
> > 
> > I would appreciate additional members of the WG to come forward and 
> > voice
> their view.
> > 
> > Thank you kindly,
> > Menachem Dodge
> > 
> > 
> > 
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]] 
> > Sent: Tuesday, November 17, 2009 11:05 AM
> > To: [email-masked]
> > Cc: Menachem Dodge; [email-masked]; [email-masked]; Moti 
> > Morgenstern;
> [email-masked]; [email-masked]
> > Subject: AW: Vector of Profiles MIB
> > 
> > Hello Scott,
> > 
> > I understand your proposal but it does not address the 
> complete issue. 
> > Operators need more flexibility of configuring their network. The 
> > approach
> of TR-129 does not scale from the OSS point view as it 
> multiplies the amount of different xDSL profiles/templates. 
> In practice, the MIB from the DSLAM (In this case represeting 
> the TR-129 object model) is usually mapped 1:1 into the EMS 
> and its data model. In FTTx deployment scenarios with 
> specific requirements depending on the PSD shaping on the 
> remote DSLAM, noise margins, specific OLR features and INP 
> configurations, TR-129 causes a multiplication of templates 
> as every single parameter variation ends up in a new template 
> and/or channel or line profile.
> > 
> > Therefore TR-165 needs to be implemented at the SNMP management 
> > interface
> and in the associated EMS to take full effect.
> > 
> > Be aware that only the profile configurtion of RFC5650 is affected, 
> > all
> other parts are untouched and can stay as they are today. In 
> order to not skip the template approach from TR-129 
> completely, a switch, as proposed by Peidaoyu from Huawei, 
> might be a good solution.
> > 
> > Regards
> > Markus
> > 
> >     
> > -----Ursprüngliche Nachricht-----
> > Von: Scott Baillie [mailto:[email-masked]]
> > Gesendet: Sonntag, 15. November 2009 13:00
> > An: Menachem Dodge; [email-masked]; [email-masked]; Moti 
> > Morgenstern;
> Freudenberger, Markus; [email-masked]; [email-masked]
> > Betreff: Re: Vector of Profiles MIB
> > 
> > Hi all,
> > 
> > As you may know from my previous messages on the subject of 
> the Vector 
> > of
> Profiles MIB proposal, I do not believe that it is a good 
> idea to introduce another VDSL2 management interface which is 
> not compatible with the existing management interface ( 
> RFC5650 ) unless there are compelling and significant reasons 
> to do so.
> > 
> > Introducing an incompatible VDSL2 management interface does not 
> > benefit
> the xDSL industry, it causes harm because NMS/EMS 
> applications will now have to support two interfaces instead of one.
> > 
> > I consider the Vector of Profiles scheme to be an implementation 
> > decision
> which should be considered by firmware developers in order to 
> minimise the storage requirements for xDSL configuration in 
> the Access Node.
> > But this implementation decision is a low level detail and 
> should not
> affect the VDSL2 management interface.
> > 
> > A firmware developer can implement the VoP scheme inside the Access 
> > Node
> while remaining 100% compatible with the RFC5650 management 
> interface. What is required is to provide a mapping between 
> the template name and the vector, and this mapping can be 
> kept hidden so that the operator has no knowledge of the 
> internal implementation details.
> > 
> > Let me state my proposal in a different way in case what I said was 
> > not
> very clear.
> > 
> > 1. Internally, the xDSL configuration is stored using
> >    the efficient VoP scheme.
> > 2. In the firmware, a mapping exists between the RFC5650
> >    template name and the internal vector that stores the
> >    configuration for that template. This mapping may take
> >    the form of a hash map for example.
> > 3. When a SNMP request arrives to read a row from the
> >    line profile or channel profile tables
> >    ( xdsl2LineConfProfTable,
> >      xdsl2LineConfProfModeSpecTable
> >      xdsl2LineConfProfModeSpecBandUsTable,
> >      xdsl2ChConfProfileTable )
> >    the access node will consult its hash map and find
> >    the corresponding vector. The access node will then
> >    retrieve the data from the vector and return it in
> >    the form of a SNMP row.
> >    What this means is that storage of the xDSL
> >    configuration data is decoupled from the MIB
> >    representation of the data. Most modern SNMP agent's
> >    ( such as the Net SNMP agent ) supports decoupling
> >    of the underlying storage as I have described.
> > 4. When a SNMP request arrives to write a row into
> >    the line profile or channel profile tables, the
> >    access node must either create a new vector to
> >    store the data of reference an existing vector
> >    which already contains that data.
> > 
> > Using this approach, the access node gains the advantage of storing 
> > the
> xDSL configuration data efficiently while remaining 
> compatible with the existing SNMP management interface.
> > 
> > The algorithm that I have described above would need to be 
> specified 
> > in
> more detail, but I am sure that every one here is an engineer 
> and at least understands the concept that I am proposing.
> > 
> > In conclusion, I think that the broad band forum should create a 
> > companion
> document that goes together with TR165 which specifies an 
> algorithm ( similar to what I have proposed above ) that 
> firmware developers can use to map between 5650 templates and 
> VoP vectors instead of specifying a new VDSL2 management 
> interface at the IETF.
> > 
> > Regards,
> > 
> > Scott.
> > 
> > 
> > _______________________________________________
> > Adslmib mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/adslmib
> 
> _______________________________________________
> Adslmib mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/adslmib
> 
> _______________________________________________
> Adslmib mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/adslmib
> 
> _______________________________________________
> Adslmib mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/adslmib
> _______________________________________________
> Adslmib mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/adslmib
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 1 Dec 2009 11:07:20 +0100

The principal problem I see this WG facing is the scarce active participation which makes progress of the chartered items happen at a painfully slow rate. I will be reluctant to consider new work items without seeing a proof that there are enough committed contributors to edit and review documents. I would suggest to people who support this work to also mention in their messages what kind of active role they are interested to take and believe that they will be able to sustain. 

Thanks and Regards,

Dan

> Sent: Monday, November 30, 2009 11:43 PM

---

From: <[email-masked]>
Date: Tue, 1 Dec 2009 11:09:43 +0100

Yes, it has to. BTW RFC 5650 does this already if you look into the abstract section. 

-----Ursprüngliche Nachricht-----
Von: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Gesendet: Dienstag, 1. Dezember 2009 11:04
An: Freudenberger, Markus; [email-masked]
Cc: [email-masked]
Betreff: RE: [Adslmib] Vector of Profiles MIB

Dan

> comment: TR-165 deals also with adsl, adsl2 and adsl2plus and not only 
> vdsl2.
> 
> Markus
> 
> An: [email-masked]; [email-masked]; 'Scott Baillie'; Moti 
> Morgenstern; Freudenberger, Markus
> Cc: [email-masked]
> Although only a small number of WG members have been involved in this 
> discussion, there has nonetheless been strong differences of opinion.
> 
> However, I would like to see if a consensus can be reached based on 
> suggestions already put forward.
> 
> 	1. The WG develops an additional optional Vdsl2 configuration 
> extension MIB based on TR-165.
>                whether VDSL2 configuration will be done by the TR-165 
> VoP Method or the TR-129 RFC 5650 Method.
> 	      b. The default of the "scalar variable" is TR-129 RFC 5650 
> Method.
> 	      c. If either the SNMP manager or the SNMP Agent do not support 
> the extension MIB and hence the "switch",
> I don't think that 10-100 profiles are enough for used to manage order 
> of
> 10^5 to 10^6 xDSL lines, maybe it's enough for adsl, but it’s not 
> enough for vdsl2. Furthermore, the memory is not the only reason to 
> define TR165.
> In FTTx or DLM or DSM cases the TR165 model is more suitable, it makes 
> configuration simpler.
> As there are two many differences between these two models, the 
> translation between TR-129 model and TR-165 model is almost 
> impossible, and makes no sense. Maybe a switch is suitable, then it up 
> to the operator to choose a management model it prefers to.
> Regards,
> PeiDaoyu
> -----邮件原件-----
> It must be possible for RFC-5650 to work independently of possible 
> optional VOP add-on.
> From very large projects in the field I'm aware of, typically,  10-100 
> profiles are used to manage order of 10^5 to 10^6 xDSL lines.
> 
> Regards,
> Umberto Bonollo
> RFC-5650 co-author
> 
> I would like to summarise my position on the Vector of Profiles MIB 
> proposal so that it is clearer what my position is, but I would like 
> to hear the views of the group on these issues.
> 
> My position
> -----------
> be developed that would contain a switch allowing either the current 
> TR-129 model or the TR-165 model to be supported.
> > 
> of TR-129 does not scale from the OSS point view as it multiplies the 
> amount of different xDSL profiles/templates.
> In practice, the MIB from the DSLAM (In this case represeting the 
> TR-129 object model) is usually mapped 1:1 into the EMS and its data 
> model. In FTTx deployment scenarios with specific requirements 
> depending on the PSD shaping on the remote DSLAM, noise margins, 
> specific OLR features and INP configurations, TR-129 causes a 
> multiplication of templates as every single parameter variation ends 
> up in a new template and/or channel or line profile.
> > 
> other parts are untouched and can stay as they are today. In order to 
> not skip the template approach from TR-129 completely, a switch, as 
> proposed by Peidaoyu from Huawei, might be a good solution.
> > 
> > Regards
> > Markus
> > 
> >     
> Profiles MIB proposal, I do not believe that it is a good idea to 
> introduce another VDSL2 management interface which is not compatible 
> with the existing management interface ( RFC5650 ) unless there are 
> compelling and significant reasons to do so.
> > 
> the xDSL industry, it causes harm because NMS/EMS applications will 
> now have to support two interfaces instead of one.
> > 
> which should be considered by firmware developers in order to minimise 
> the storage requirements for xDSL configuration in the Access Node.
> while remaining 100% compatible with the RFC5650 management interface. 
> What is required is to provide a mapping between the template name and 
> the vector, and this mapping can be kept hidden so that the operator 
> has no knowledge of the internal implementation details.
> > 
> xDSL configuration data efficiently while remaining compatible with 
> the existing SNMP management interface.
> > 
> more detail, but I am sure that every one here is an engineer and at 
> least understands the concept that I am proposing.
> > 
> document that goes together with TR165 which specifies an algorithm ( 
> similar to what I have proposed above ) that firmware developers can 
> use to map between 5650 templates and VoP vectors instead of 
> specifying a new VDSL2 management interface at the IETF.
> > 
> > Regards,
> > 
> > Scott.
> > 
> >

---

From: Menachem Dodge <[email-masked]>
Date: Thu, 3 Dec 2009 10:12:20 +0200

Hi All,

	The WG is kindly requested to respond as to whether:

	1. The proposal for work on the extension is acceptable or not.
	2. If you support this work, whether you will be able to take an active role in developing the draft.

Best Regards,
Menachem

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Tuesday, December 01, 2009 12:07 PM
To: [email-masked]; Menachem Dodge
Cc: [email-masked]; Moti Morgenstern
Subject: RE: [Adslmib] Vector of Profiles MIB

Thanks and Regards,

Dan

---

From: <[email-masked]>
Date: Mon, 7 Dec 2009 13:41:48 +0100

Hello Menachem,

Regarding 1)
as already stated, I support the MIB extension for TR-165 Support.
 
Regarding 2)
Yes, I can provide material for developing the draft.

Regards
Markus

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Menachem Dodge
Gesendet: Donnerstag, 3. Dezember 2009 09:12
An: [email-masked]
Betreff: Re: [Adslmib] Vector of Profiles MIB

Hi All,

Best Regards,
Menachem

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]]
Sent: Tuesday, December 01, 2009 12:07 PM
To: [email-masked]; Menachem Dodge
Cc: [email-masked]; Moti Morgenstern
Subject: RE: [Adslmib] Vector of Profiles MIB

Thanks and Regards,

Dan

---

From: Menachem Dodge <[email-masked]>
Date: Tue, 8 Dec 2009 11:43:59 +0200

Hello Markus,

Thank you kindly for your response.

Once again the WG is kindly requested to indicate, by Thursday 10th December, as to whether:

Best Regards,
Menachem

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, December 07, 2009 2:42 PM
To: Menachem Dodge; [email-masked]
Subject: Re: [Adslmib] Vector of Profiles MIB

Hello Menachem,

Regarding 1)
 
Regarding 2)

Regards
Markus

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Menachem Dodge
Gesendet: Donnerstag, 3. Dezember 2009 09:12
An: [email-masked]
Betreff: Re: [Adslmib] Vector of Profiles MIB

Hi All,

Best Regards,
Menachem

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]]
Sent: Tuesday, December 01, 2009 12:07 PM
To: [email-masked]; Menachem Dodge
Cc: [email-masked]; Moti Morgenstern
Subject: RE: [Adslmib] Vector of Profiles MIB

Thanks and Regards,

Dan

---

From: Moti Morgenstern <[email-masked]>
Date: Tue, 8 Dec 2009 16:01:49 +0200

Hi,

1) I think it will be very helpful to have the VoP documented at least as an extension to RFC5650. However, it's essential that a meaningful number of technical people from various companies are actively involved. Otherwise, the result will be sub-optimal.
2) My willingness to contribute depends on the support level from the WG members for this effort.

BR, Moti
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Menachem Dodge
Sent: Tuesday, December 08, 2009 11:44 AM
To: [email-masked]; [email-masked]
Subject: Re: [Adslmib] Vector of Profiles MIB

Hello Markus,

Best Regards,
Menachem

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, December 07, 2009 2:42 PM
To: Menachem Dodge; [email-masked]
Subject: Re: [Adslmib] Vector of Profiles MIB

Hello Menachem,

Regarding 1)

Regarding 2)

Regards
Markus

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Menachem Dodge
Gesendet: Donnerstag, 3. Dezember 2009 09:12
An: [email-masked]
Betreff: Re: [Adslmib] Vector of Profiles MIB

Hi All,

Best Regards,
Menachem

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]]
Sent: Tuesday, December 01, 2009 12:07 PM
To: [email-masked]; Menachem Dodge
Cc: [email-masked]; Moti Morgenstern
Subject: RE: [Adslmib] Vector of Profiles MIB

Thanks and Regards,

Dan

---

From: "Barchmann, Gerd (NSN - DE/Greifswald)" <[email-masked]>
Date: Thu, 10 Dec 2009 08:31:36 +0100

Hello,

1) VoP proposal should become an RFC extension.  
2) I'm willing to support this work.

	Gruß/Regards Gerd 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Moti Morgenstern
Sent: Tuesday, December 08, 2009 3:02 PM
To: Menachem Dodge
Cc: [email-masked]; [email-masked]
Subject: Re: [Adslmib] Vector of Profiles MIB

Hi,

BR, Moti
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Menachem Dodge
Sent: Tuesday, December 08, 2009 11:44 AM
To: [email-masked]; [email-masked]
Subject: Re: [Adslmib] Vector of Profiles MIB

Hello Markus,

Best Regards,
Menachem

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, December 07, 2009 2:42 PM
To: Menachem Dodge; [email-masked]
Subject: Re: [Adslmib] Vector of Profiles MIB

Hello Menachem,

Regarding 1)

Regarding 2)

Regards
Markus

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Menachem Dodge
Gesendet: Donnerstag, 3. Dezember 2009 09:12
An: [email-masked]
Betreff: Re: [Adslmib] Vector of Profiles MIB

Hi All,

Best Regards,
Menachem

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]]
Sent: Tuesday, December 01, 2009 12:07 PM
To: [email-masked]; Menachem Dodge
Cc: [email-masked]; Moti Morgenstern
Subject: RE: [Adslmib] Vector of Profiles MIB

Thanks and Regards,

Dan

---

From: "VAN DER PUTTEN Frank" <[email-masked]>
Date: Thu, 10 Dec 2009 09:11:32 +0100

Hello Menachem,

My answers to your questions:

I see a value in the "Vector of Profiles" concept in a residential mass-market DSL environment, since it creates a higher configuration flexibility. Although changing the object model causes a significant migration effort for existing deployments based on the TR-129 object model, I do not oppose this work being started in IETF.

I won't be able to take an active role in creation of IETF documents, but am glad to review contributions and provide feedback.

Thanks,
Frank Van der Putten
Alcatel-Lucent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Menachem Dodge
Sent: donderdag 3 december 2009 9:12
To: [email-masked]
Subject: Re: [Adslmib] Vector of Profiles MIB

Hi All,

Best Regards,
Menachem

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Tuesday, December 01, 2009 12:07 PM
To: [email-masked]; Menachem Dodge
Cc: [email-masked]; Moti Morgenstern
Subject: RE: [Adslmib] Vector of Profiles MIB

Thanks and Regards,

Dan

---

From: Menachem Dodge <[email-masked]>
Date: Thu, 10 Dec 2009 19:27:16 +0200

Hello,

So far I have 4 people "in-favor" and one person "not-opposed" to this work. All of these people are willing
to support the work in one form or another.

This is the last call for anyone else who wishes to respond!

Thank you kindly.
Menachem

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Menachem Dodge
Sent: Tuesday, December 08, 2009 11:44 AM
To: [email-masked]; [email-masked]
Subject: Re: [Adslmib] Vector of Profiles MIB

Hello Markus,

Best Regards,
Menachem

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, December 07, 2009 2:42 PM
To: Menachem Dodge; [email-masked]
Subject: Re: [Adslmib] Vector of Profiles MIB

Hello Menachem,

Regarding 1)

Regarding 2)

Regards
Markus

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Menachem Dodge
Gesendet: Donnerstag, 3. Dezember 2009 09:12
An: [email-masked]
Betreff: Re: [Adslmib] Vector of Profiles MIB

Hi All,

Best Regards,
Menachem

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]]
Sent: Tuesday, December 01, 2009 12:07 PM
To: [email-masked]; Menachem Dodge
Cc: [email-masked]; Moti Morgenstern
Subject: RE: [Adslmib] Vector of Profiles MIB

Thanks and Regards,

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 10 Dec 2009 18:32:45 +0100

>From an AD perspective this number of four individuals is marginal. Actually it’s rather on the red side of the margin. 

Question - does the figure four include the chair? Do you have a designated editor? Does the figure of four include him or her? 

Second Question - would the few people involved be favorable of taking this work to OPSAWG which is chartered among other with doing incremental MIB work such as this one?  

Thanks and Regards,

Dan

> [mailto:[email-masked]] On Behalf Of Menachem Dodge
> Sent: Thursday, December 10, 2009 7:27 PM
> So far I have 4 people "in-favor" and one person 
> "not-opposed" to this work. All of these people are willing 
> [mailto:[email-masked]] On Behalf Of Menachem Dodge
>         2. If you support this work, whether you will be able 
> to take an active role in developing the draft.
> 
> 
> Best Regards,
> Menachem
> 
> 
> 
> 
> [mailto:[email-masked]] Im Auftrag von Menachem Dodge
>         2. If you support this work, whether you will be able 
> to take an active role in developing the draft.
> 
> Best Regards,
> Menachem
> 
> 
> 
> The principal problem I see this WG facing is the scarce 
> active participation which makes progress of the chartered 
> items happen at a painfully slow rate. I will be reluctant to 
> consider new work items without seeing a proof that there are 
> enough committed contributors to edit and review documents. I 
> would suggest to people who support this work to also mention 
> in their messages what kind of active role they are 
> interested to take and believe that they will be able to sustain.
> 
> Thanks and Regards,
> 
> Dan
> 
> 
> the TR-165 
> >             c. If either the SNMP manager or the SNMP Agent do not 
> > support the extension MIB and hence the "switch",
> manage order 
> typically,  10-100 
> multiplies the 
> interface.
> algorithm (

---

From: Menachem Dodge <[email-masked]>
Date: Thu, 10 Dec 2009 21:00:49 +0200

Hi Dan,

I agree with you that the number of people supporting the work is marginal, and was hoping that a few more people would speak up in support of this work.

The number does not include myself, so there are five involved people.

I haven't appointed an editor as yet but the editor would be included in this figure.

Although there are only a few active people, there are always additional people on the mailing list who provide feedback.
By moving the work to the OPSAWG I think we may lose their comments. However, I would be interested to hear what others think.

Best Regards,
Menachem

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]]
Sent: Thursday, December 10, 2009 7:33 PM
To: Menachem Dodge; [email-masked]
Subject: RE: [Adslmib] Vector of Profiles MIB

Thanks and Regards,

Dan

---

From: Scott Baillie <[email-masked]>
Date: Thu, 17 Dec 2009 16:33:08 +1100

Hi Menachem,

I am willing to contribute to the extension but I think we
first need to agree on some rules regarding inter-operability
between RFC5650 compliant and extension compliant entities
because creating an extension will have consequences on existing
RFC5650 implementations.

Some of my suggestions are :
- Add the switch to RFC5650. The reason for this is that
  a RFC5650 compliant manager must have the ability to
  switch the agent back to TR129 mode.
- A SNMP agent that complies with the extension must
  also implement a fully manageable TR129 mode. It would
  not be acceptable for the agent to implement TR165 mode
  only and not support management of the hardware via TR129 mode.

Regards,

Scott.