Re: two questions on draft-ietf-adslmib-gbond-mib-10

Hi, 

I apologize for the delayed response. Vacation interfered, and it looks
like I never answered this mail. 

1. You seem to agree with me that there may be a need to change the
common MIB module if new bonding schemes are defined. Building a more
modular scheme, possibly by defining IANA administered TC for
GBondSchemeList and GBondScheme could avoid at least part of the pain.
It's up to you and Benoit to decide if you want to do it now, or maybe
progress now the document as it is and deal with the issued later when
and if new bonding schemes appear. This is why I asked you how probable
this event is, I do not think that you answered). 

2. I can live with this explanation. 

Regards,

Dan
 



> -----Original Message-----
> From: Menachem Dodge [mailto:[email protected]]
> Sent: Wednesday, April 04, 2012 11:45 AM
> To: Moti Morgenstern; Romascanu, Dan (Dan); Benoit Claise
> <[email protected]> ([email protected])
> Cc: [email protected]; adslmib mailing list; Edward Beili
> Subject: RE: [Adslmib] two questions on
draft-ietf-adslmib-gbond-mib-10
> 
> Hi,
> 
> Has  this response adequately answered the issues/concerns or is
> further clarification required?
> 
> Thank you kindly.
> 
> Menachem
> 
> 
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Moti Morgenstern
> Sent: Wednesday, March 28, 2012 11:37 AM
> To: Romascanu, Dan (Dan)
> Cc: [email protected]; adslmib mailing list; Edward Beili
> Subject: Re: [Adslmib] two questions on
draft-ietf-adslmib-gbond-mib-10
> 
> Hi Dan,
> 
> I previously didn't send my opinion as the 'To' list included Ed
alone.
> However, if it matters, the following is (briefly) my answer to those
> questions.
> 
> 1) New Bonding Schemes
> Each new scheme will probably require developing a MIB for it. The
> 'common' MIB module is not expected to be modified too much, but it's
> obvious that it would not be left untouched. As a minimum, every
> component that currently mentions the existing bonding schemes will
> need to mention the 'new' scheme as well. I mean, shouldn't the MIB
> document describe its applicability to the 'new' scheme and indicate
> the reference standard? Shouldn't the edge devices exchange their
> capability to support that scheme? Etc.
> 
> 2) GBondSchemeList
> I think that it's up to the implementation to decide whether or not it
> wishes to distinguish between a device that explicitly reports it
> doesn't support any of the 3 standard schemes and a device that simply
> didn't report so far its capability. The value 0 may be sufficient for
> both (because in both cases it's impossible for the edge devices to
> agree on a scheme at the moment) and then the optional value 'none'
> won't be supported.
> BTW, we are familiar with textual conventions for failures/alarms in
> which the value 0 means: 'no problem' while there are other TCs in
> which the 'no problem' is allocated its own bit-position, correct?.
> 
> Best Regards (and good luck in your future projects), Moti
> 
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Romascanu, Dan (Dan)
> Sent: Wednesday, March 28, 2012 11:00 AM
> To: Romascanu, Dan (Dan); Edward Beili
> Cc: [email protected]; adslmib mailing list
> Subject: Re: [Adslmib] two questions on
draft-ietf-adslmib-gbond-mib-10
> 
> I do not think that I saw answers to these questions yet. As I am
> transferring today my yellow dot and AD responsibilities to Benoit,
> this document together with eth-mib transfer to him, and hopefully the
> remaining issues will be quickly answered.
> 
> Dan
> 
> 
> 
> 
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On
> > Behalf Of Romascanu, Dan (Dan)
> > Sent: Wednesday, March 21, 2012 3:28 PM
> > To: Edward Beili
> > Cc: [email protected]; adslmib mailing list
> > Subject: [Adslmib] two questions on draft-ietf-adslmib-gbond-mib-10
> >
> > Hi Ed,
> >
> > The I-D draft-ietf-adslmib-gbond-mib-10 was approved by the IESG
with
> > 'point raised'. This means that I would like to get clarification
> from
> > you (and the WG if needed) on a couple of points before approving
the
> > document.
> >
> > The two questions derive from the COMMENT entered by Adrian Farrel.
> > They
> > are non-blocking from his perspective, yet I think that they are
> > interesting enough to deserve being answered, even if they do not
> lead
> > to changes in the document.
> >
> > 1.  How likely is it that new bonding schemes (i.e. other
> > technologies) will come along and be handled by this MIB module
> without
> > extensions? I think the intention is that this module is technology-
> > independent, so that it would not need to be revised for a new
> bonding
> > type.
> >
> > However, GBondSchemeList and GBondScheme are closed lists such that
> you
> > would need to revise the module to support new technologies. That
> seems
> > a shame.
> >
> > You could move the TCs into a separate module so that only that
> module
> > needs to be revised.
> >
> > An alternative, is to define an IANA Textual convention for this and
> > allow just the TC to be updated as necessary.
> >
> > ---
> >
> > 2. I find the presence of 'unknown' as a bit in GBondSchemeList to
be
> a
> > bit
> > odd. In general, bits in an object with a Syntax of Bits can be
> > independently set. But here you could not set 'unknown' and any of
> the
> > other bits.
> >
> > On the other hand, what would it mean to return the object with none
> of
> > the bits set? Is that different from returning the 'unknown' bit?
> >
> > Please address these two questions.
> >
> > Thanks and Regards,
> >
> > Dan
> >
> >
> >
> > _______________________________________________
> > Adslmib mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/adslmib
> _______________________________________________
> Adslmib mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/adslmib
> 
> This e-mail message is intended for the recipient only and contains
> information which is CONFIDENTIAL and which may be proprietary to ECI
> Telecom. If you have received this transmission in error, please
inform
> us by e-mail, phone or fax, and then delete the original and all
copies
> thereof.
> 
> _______________________________________________
> Adslmib mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/adslmib
> 
> 
> This e-mail message is intended for the recipient only and contains
> information which is CONFIDENTIAL and which may be proprietary to ECI
> Telecom. If you have received this transmission in error, please
inform
> us by e-mail, phone or fax, and then delete the original and all
copies
> thereof.