Subject: Re: [Adslmib] two questions on draft-ietf-adslmib-gbond-mib-10

From: Menachem Dodge <[email-masked]>
Date: Wed, 4 Apr 2012 11:45:20 +0300

Hi,

Has  this response adequately answered the issues/concerns or is further clarification required? 

Thank you kindly.

Menachem

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Moti Morgenstern
Sent: Wednesday, March 28, 2012 11:37 AM
To: Romascanu, Dan (Dan)
Cc: [email-masked]; 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-masked] [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Wednesday, March 28, 2012 11:00 AM
To: Romascanu, Dan (Dan); Edward Beili
Cc: [email-masked]; 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-masked] [mailto:[email-masked]] On 
> Behalf Of Romascanu, Dan (Dan)
> Sent: Wednesday, March 21, 2012 3:28 PM
> To: Edward Beili
> Cc: [email-masked]; 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-masked]
> https://www.ietf.org/mailman/listinfo/adslmib
_______________________________________________
Adslmib mailing list
[email-masked]
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-masked]
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.

---

From: Benoit Claise <[email-masked]>
Date: Tue, 17 Apr 2012 10:39:02 +0200

Hi Mechanem,

Thanks for your answer.
I would like to see the text proposal, answering both Dan's points and 
Adrian's comments (part of the IESG review)

For your convenience, here are Adrian's comments again:

    *Comment (2012-03-15)*

    I have no objection to the publication of this document.

    I have a number of small Comments. They are non-blocking and you can
    take them or leave them

    ---

    The shepherd write-up appears to disagree with the ballot write-up wrt
    implementations. I choose to believe the shepherd not the AD since the
    shepherd gives better news!

    ---

    It is not necessary to say the document "proposes". You can say
    "defines".

    ---

    Thanks for the detail in Section 4. It really helps.

    ---

    Question for you. 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.

    ---

    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?

    ---

    gBondLowUpRateCrossing Description
    s/port'/port's/

Regards, Benoit.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 23 Apr 2012 14:01:53 +0200

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

> From: Menachem Dodge [mailto:[email-masked]]
> Sent: Wednesday, April 04, 2012 11:45 AM
> To: Moti Morgenstern; Romascanu, Dan (Dan); Benoit Claise
> <[email-masked]> ([email-masked])
> Subject: RE: [Adslmib] two questions on
draft-ietf-adslmib-gbond-mib-10
> Behalf Of Moti Morgenstern
> 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?.
> 
> 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
> 
> 
> 
> 
> 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.
> 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.