Re: two questions on draft-ietf-adslmib-gbond-mib-10
Benoit Claise <[email protected]> Tue, 17 Apr 2012 10:39:02 +0200
| Newsgroups | gmane.ietf.adslmib |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============5025998294057629917==
Content-Type: multipart/alternative;
boundary="------------090005010909030804070501"
This is a multi-part message in MIME format.
--------------090005010909030804070501
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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.
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.
---
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.
> 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.
>
>
>
--------------090005010909030804070501
Content-Type: multipart/related;
boundary="------------080208070203070505080608"
--------------080208070203070505080608
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Mechanem,<br>
<br>
Thanks for your answer.<br>
I would like to see the text proposal, answering both Dan's points
and Adrian's comments (part of the IESG review)<br>
<br>
For your convenience, here are Adrian's comments again:<br>
<blockquote>
<p><b>Comment (2012-03-15)</b> <img
src="cid:[email protected]" alt="" height="12"
width="14"></p>
<pre>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.
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.
---
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/</pre>
</blockquote>
Regards, Benoit.<br>
<br>
<blockquote
cite="mid:283DD79798619346BF9B17D7B5035A190185391BCA23@ILPTMAIL02.ecitele.com"
type="cite">
<pre wrap="">Hi,
Has this response adequately answered the issues/concerns or is further clarification required?
Thank you kindly.
Menachem
-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> [<a class="moz-txt-link-freetext" href="mailto:[email protected]">mailto:[email protected]</a>] On Behalf Of Moti Morgenstern
Sent: Wednesday, March 28, 2012 11:37 AM
To: Romascanu, Dan (Dan)
Cc: <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>; 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: <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> [<a class="moz-txt-link-freetext" href="mailto:[email protected]">mailto:[email protected]</a>] On Behalf Of Romascanu, Dan (Dan)
Sent: Wednesday, March 28, 2012 11:00 AM
To: Romascanu, Dan (Dan); Edward Beili
Cc: <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>; 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
</pre>
<blockquote type="cite">
<pre wrap="">-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> [<a class="moz-txt-link-freetext" href="mailto:[email protected]">mailto:[email protected]</a>] On
Behalf Of Romascanu, Dan (Dan)
Sent: Wednesday, March 21, 2012 3:28 PM
To: Edward Beili
Cc: <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>; 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
</pre>
</blockquote>
<pre wrap="">without
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">you
</pre>
<blockquote type="cite">
<pre wrap="">would need to revise the module to support new technologies. That
</pre>
</blockquote>
<pre wrap="">seems
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">a
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">of
</pre>
<blockquote type="cite">
<pre wrap="">the bits set? Is that different from returning the 'unknown' bit?
Please address these two questions.
Thanks and Regards,
Dan
_______________________________________________
Adslmib mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/adslmib">https://www.ietf.org/mailman/listinfo/adslmib</a>
</pre>
</blockquote>
<pre wrap="">_______________________________________________
Adslmib mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/adslmib">https://www.ietf.org/mailman/listinfo/adslmib</a>
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
<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/adslmib">https://www.ietf.org/mailman/listinfo/adslmib</a>
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.
</pre>
</blockquote>
<br>
</body>
</html>
--------------080208070203070505080608
Content-Type: image/png;
name="comment.png"
Content-Transfer-Encoding: base64
Content-ID: <[email protected]>
Content-Disposition: inline;
filename="comment.png"
iVBORw0KGgoAAAANSUhEUgAAAA4AAAAMCAYAAABSgIzaAAAA/ElEQVQoz6WSO27DMAyG0xym
h+gFOvUI3YPMOYS7pkOBTjlBllzD74f8lC3Z1pbZ619RjYOoDYIAIUBAAz99pKjF4tFYOQLP
r7ubSTU6nizo63sHIQRa3qKuaxRFgSzLkCQJwjCA53lwtnsbptuUUuj7Hl3XoWk4qqoCy3Ok
aYIoiuD7PlzXNeZ/4DCMEPLXWl1Y45isobGewKUFKjWerZw32loiz5m2phqOEQSBDVLfzuf+
BGvzOECSudXzNtpclmCMmRprRjr8fdXVxwBhzNwA75vDDC2tdRB8mQRLKQ1E55f18c1axbWg
wmmajGWG7voMc7t3Wa61favmB+KXRaNbDO3XAAAAAElFTkSuQmCC
--------------080208070203070505080608--
--------------090005010909030804070501--
--===============5025998294057629917==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Adslmib mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/adslmib
--===============5025998294057629917==--