RE: RFC3276 respin

Inline

> -----Original Message-----
> From: Bob Ray [mailto:[email protected]]
> Sent: woensdag 11 februari 2004 16:19
> To: Bert (Bert) Wijnen
> Cc: adslmib mail list
> Subject: RE: [Adslmib] RFC3276 respin
> 
> 
> 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.
> 
Yes it is allowed.

In general though, we have adopted the technique (certainly if they
are write-able objects, which I have not yet checked in thsi case)
to then change the existing MODULE-COMPLIANCE to list the old enumerations
explicitly. This is to ensure that any implementation that claims compliance
with the existing MODULE-COMPLIANCE is not impacted and still has a very 
clear statement of what they do and do not support. Easu enought to do,
so should not be an issue.

> > 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
> 

Nope, the OBJECT-TYPE would change (formally not allowed, so you must
convince me and the community that it is OK... as I said, I think
I personally can go along). SO new object would looke like

   hdsl2ShdslStatusMaxAttainableLineRate OBJECT-TYPE
      SYNTAX      Unsigned32(0..92520000)
      blah blah blah

I wonder though if we may need to change it a agin a few years
from now. So maybe just remove the range all together?

> 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."
> 
Nope, in the compliance section you would get something aka:

hdsl2ShdslLineMibCompliance MODULE-COMPLIANCE
   STATUS       current
   DESCRIPTION "The compliance statement for a managed entity that 
                supports the orginal g.shdsl specification."
   blabla
   OBJECT      hdsl2ShdslStatusMaxAttainableLineRate
               SYNTAX       Unsigned32(0..4112000)
               DESCRIPTION "An implementation only has to support the
                            range as applicable for the original g.shdsl
                            specification."
   blabla
   ::= { hdsl2ShdslCompliances 1 }

And in a new compliance statement you eitehr leave it out or add some text.
So something aka:

hdsl2ShdslBisLineMibCompliance MODULE-COMPLIANCE
   STATUS       current
   DESCRIPTION "The compliance statement for a managed entity that 
                supports the enhanced g.shdsl.bis specification."
   blabla
   OBJECT      hdsl2ShdslStatusMaxAttainableLineRate
               SYNTAX       Unsigned32(0..92520000)
               DESCRIPTION "An implementation only has to support the
                            range as applicable for the original g.shdsl
                            specification."
   blabla
   ::= { hdsl2ShdslCompliances 2 }

Or possibly the last one supports both original g.shdsl and the new
g.shdsl.bis specifications, in which case the text changes a bit.



> 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)?
> 
Nope, you do similar things as I explained above.

> 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.
>
There are examples, for example look at rfc2096upd specs

but let us go and elaborate on this specific case

> 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 :)
> 
Nope. You do the following:

Update the TC itself:

Hdsl2ShdslWirePair ::= TEXTUAL-CONVENTION
   STATUS    current
   DESCRIPTION
     "This is the referenced pair of wires in a HDSL2/SHDSL Segment.
      HDSL2 only supports a single pair (wirePair1), while SHDSL
      supports an optional second pair (wirePair2)."
   SYNTAX    INTEGER
           {
           wirePair1(1),
           wirePair2(2),
           wirePair3(3),
           wirePair4(4)
           }

Of course you need to update the description clause above as well.

Leave the OBJECT-TYPE definitions untouched.

In the MODULE-COMPLIANCE (existing one) add text (since the usage
of this TC is in an INDEX object, you cannot add it as machine
readable spec in the MODULE-COMPLIANCE. So taking the above,
and adding thios, it would become something aka:

hdsl2ShdslLineMibCompliance MODULE-COMPLIANCE
   STATUS       current
   DESCRIPTION "The compliance statement for a managed entity that 
                supports the orginal g.shdsl specification.

                There is an INDEX object that cannot be represented
                in the form of OBJECT clauses in SMIv2, but for which
                there are compliance requirements, expressed in OBJECT
                clause form in this description:
                -- OBJECT      hdsl2ShdslEndpointWirePair
                -- SYNTAX      Hdsl2ShdslWirePair (wirePair1(1),
                --                 wirePair2(2))
                -- DESCRIPTION
                --     This compliance (for g.shdsl) only requires 
                --     support for wirePair1 and wirePair2.
                --             
               "
   blabla
   OBJECT      hdsl2ShdslStatusMaxAttainableLineRate
               SYNTAX       Unsigned32(0..4112000)
               DESCRIPTION "An implementation only has to support the
                            range as applicable for the original g.shdsl
                            specification."
   blabla
   ::= { hdsl2ShdslCompliances 1 }

Now.. pls check, because the text may need to change somewhat here and there.
Possibly where I say "g.shdsl" maybe it should say "hdsl and g.shdls..."
or some such, but you know this better than I do.


> 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?
>
If the WG decides this is what they want to do (I can see that as part
of the charter I think, WG chair chime in what you think) then it is
up to the WG chair to decide if he wants to adopt it right away
or if he rathers sees an individual draft first that teh WG then can
discuss fiorst before adopting the document. 

> b) Would this draft contain the full text of RFC3276 in draft form (vs
> RFC form) along with the above modifications?
> 
That is one way of doing it. Note that you can ask RFC-editor for the
nroff source for rfc3276.

Another way (with far less text, but a bit more complex process wise
cause we have only done it once sofar is to use the approach
as done for the updates to rmon and rmon2 in RFC3273.txt, sect 3. 
AT the end of section 3, it then points to updated MIB modules.
Those updated mib modules actually also contain examples of how
enumerations were added and how they were dealt with in compliance
section.


> 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?
> 
Yep (as was done for rmon1 and rmon2), but you MUST also provide
an updated MIB module (as was done for rmon1 and rmon2).
And the pointers to those need to go into the I-D as well and 
the new modules MUST be posted (temproarily) on internet-drafts,
so that people can see them.

For the hcrmon (RFC3273) they were listed in revision 10 of the
spec as:

   For convenience, updated MIB modules containing these objects may be
   found at:
   http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-hcrmon-08-rmon.mib
   http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-hcrmon-08-rmon2.mib

   Note to RFC-Editor: above 2 links to be updated to RFC-Editor location
                       when RFC-is published


Hope this helps/explains,
bert