Re: RFC3276 respin

Bob and Bert,

Thanks for moving this forward.

On the limits for the rates, I think a lot of tools that compile MIBs 
for agents and managers may actually generate code to check any 
specified limits. I seem to recall, for example, the SNMP Research 
product does that. They may not actually use the MODULE-COMPLIANCE. If 
you would like, I could send them an email and ask them. Just let me know.

If we can hammer out these details, with some guidance, I would be 
willing to help in any way. My employer won't send me to IETF meeting, 
but if there is anything I can do to help, I'm willing. It sounds like a 
great opportunity to learn the process and enable me to contribute in 
the future.

Thanks!
Clay


Bob Ray wrote:

>On Wed, 2004-02-11 at 06:34, Wijnen, Bert (Bert) wrote:
>
>  
>
>>Formally, I do not think that you can remove the range limits.
>>See RFC2578, sect 10.
>>    
>>
>
>Adding additional enumerations to Hdsl2ShdslWirePair and
>hdsl2ShdslSpanConfWireInterface are certainly allowed by 2578,
>section 10.2 note (1), so that is straight forward.
>
>  
>
>>I think I could go along with the change if we were to update the
>>current MODULE-COMPLIANCE such that the current ranges are inlcuded
>>there, and then do a new MODULE-COMPLIANCE that allows for the new
>>values, certainly for the read-write objects. 
>>
>>Similar fixes to MODULE-COMPLIANCE would be recommend for the enumerated
>>objects.
>>    
>>
>
>I'm trying to understand - please bear with me.
>
>So, one would leave the original object declaration alone, such as:
>
>hdsl2ShdslStatusMaxAttainableLineRate OBJECT-TYPE
>   SYNTAX      Unsigned32(0..4112000)
>   blah blah blah
>
>but add entries in the compliance section of the form:
>
>OBJECT      hdsl2ShdslStatusMaxAttainableLineRate
>            SYNTAX   Unsigned32(0..92520000)
>            DESCRIPTION
>                 "An extended range is applicable when implementing
>		  g.shdsl.bis."
>
>Is this right?  If so, I guess similar entries would be required for 
>	hdsl2ShdslStatusActualLineRate,
>	hdsl2ShdslSpanConfMinLineRate, and 
>	hdsl2ShdslSpanConfMaxLineRate.
>
>For hdsl2ShdslSpanConfWireInterface, then, would the following be
>the right syntax (in the compliance section)?
>
>OBJECT      hdsl2ShdslSpanConfWireInterface
>            SYNTAX      INTEGER
>            {
>               twoWire(1),
>               fourWire(2),
>               sixWire(3),
>               eightWire(4)
>            }
>            DESCRIPTION
>                 "An extended range is applicable when implementing
>		  g.shdsl.bis."
>
>If the above is correct, then, the only one left is the textual
>convention Hdsl2ShdslWirePair.  How does one extend a textual convention
>in the compliance section?  I don't think I've ever seen this done.
>
>Does one add an entry stating:
>
>TEXTUAL-CONVENTION Hdsl2ShdslWirePair
>           SYNTAX    INTEGER
>           {
>           wirePair1(1),
>           wirePair2(2),
>           wirePair3(3),
>           wirePair4(4)
>           }
>           DESCRIPTION
>                 "An extended range is applicable when implementing
>		  g.shdsl.bis."
>
>Looks odd, I guess, but I don't know the way :)
>
>Process questions
>
>a) Were some industrious person to submit a "respin of 3276" with the above
>changes, would they submit a new draft to the ietf draft editor as an
>individual contribution or striaght away to the adslmib working group?
>
>b) Would this draft contain the full text of RFC3276 in draft form (vs
>RFC form) along with the above modifications?
>
>c) Would it be permissible to submit a draft noting the changes necessary
>to support g.shdsl.bis?  That is, essentially a draft with all of the
>above changes discussed textually ala RFC3593?
>
>Bob
>
>
>_______________________________________________
>Adslmib mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/adslmib
>  
>