Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10)

From: "Eduardo Cardona" <[email-masked]>
Date: Tue, 13 Apr 2004 19:25:48 -0600

Hi, 

That's a very good detailed analysis for the proposed changes, 

Before going to a detail response, RFI MIBv2 is an update of RFC 2670, 
V2 introduces in brief :
*DOCSIS 2.0 new burst profiles ( in terms of extensions of existing
enumerations)
*Upstream Channels SCDMA parameters in docsIfUpstreamChannelTable
*Utilization and DOCSIS MAC Counters 
     docsIfCmtsChannelUtilizationTable,
docsIfCmtsDownChannelCounterTable, docsIfCmtsUpChannelCounterTable
*Added some objects in docsIfCmtsCmStatusTable

The other set of objects related to not DOCSIS 2.0 enhanced
functionality were not updated nor the wording of RFC2670 original
objects in terms of OPS guidelines being leaved as they were in RFC
2670.

Proposed changes are in two categories, 
1..4 Modulation Profiles StorageType object

5..8 read-write/read-create objects not upgraded by DOCSIS 2.0 that
could be questioned by IESG in terms of OPS MIB guidelines for not
indicating persistence requirements.

Note that 5..8 all have compliance statements that allows MIN-ACCESS
read-only back in RFC 2670
The disjunctive here is be OPS MIB guidelines compliance without
introduce new requirements or indeed introduce new technical changes
(persistence MUST) not identified before.

Options :
5..8 a) as proposed (explicit vendor specific, not interoperable, with
the precendent of read-only compliances)
     b) turn as MUST (new requirement: sent proposal back to IPCDN group
and DOCSIS groups for approval)
     c) leave silent as in RFC 2670 (not introduce changes 5..8)

a) or b) will be my options, I started with a) due the b) implications.

See inline some specific comments 

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Tuesday, April 13, 2004 12:57 PM
To: [email-masked]
Subject: Re: [ipcdn] Changes for next RFI v2 MIB (draft 10)

Hi -

I was able to extract the text from that PDF file, so I have some more
detailed comments in-line below.

> From: "Eduardo Cardona" <[email-masked]>
> To: "Donati Andrew-MGIA0477" <[email-masked]>; <[email-masked]>
> Sent: Monday, April 12, 2004 3:51 PM
> Subject: [ipcdn] Changes for next RFI v2 MIB (draft 10)
...
> Change #2
> docsIfCmtsModulationEntry OBJECT-TYPE
...
> Initial default entries may be created at system

I think you mean "MAY"

<edo>
Will update all document to upper cases MAY, MUST, MUST NOT
</edo>

> initialization time, which could report for a value 'permanent' or 
> 'readOnly' for docsIfCmtsModStorageType.

Is "could report" intended to mean that this is the complete set of
values that can be returned by a conformant implementation?

> A CMTS may not allow the creation of additional Interval Usage Codes 
> for a modulation profile being defined at Initialization time.

Does "may not" here mean "MUST NOT" or "MAY"?
<edo>
A bit clear saying :
"A CMTS MAY allow...."
</edo>
...

> Note that some objects do not have default value ,

 I think you mean "values"

<edo>
Yes, and may leave as he original RFC 2670 version and previous drafts.
"Note that some objects do not have DEFVALs,"
</edo>
...
> upstream channels, the value of docsIfCmtsModChannelType
> MUST NOT be changed.

This is ambiguous.  Three readings possible:
   a) agent must not change the value it reports over time
   b) agent must not permit SET requests to modify the value
   c) both (a) AND (b)

...

> MUST NOT be set to destroy(6) or notInService(2)."

ditto

...

<edo>
(a) and (b); 
Not sure how (a)is put in context,  docsIfCmtsModChannelType is a 
Configuration parameter.

An alternative: 

1. If a modulation profile is being referenced by one or more
   upstream channels, an attempt to set the value of 
   docsIfCmtsModChannelType returns 'inconsistentValue' error.

2. If a modulation profile is being referenced by one or more
   upstream channels, an attempt to set docsIfCmtsModControl
   to destroy(6) or notInService(2) returns 'inconsistentValue'
   error.
</edo>

> CHANGE # 5
> docsIfUpChannelStatus OBJECT-TYPE
...
> 1. Entries with this object set to active(1) are
> logically linked to a defined physical interface in
> the interface MIB RFC 2863, no temporarily created to
> clone parameters.

I think you mean "not" instead of "no".
(Even so, as a non-expert, it's still unclear to me what
this sentence is supposed to mean.)
<edo>
Agree, Although text current text was discussed discussed in the IPCDN
list 
back around October 10 to 15 (eventually closed to experts in the topic)

             1. Entries with this object set to active(1) are 
                extensions of defined physical interfaces in 
                the interface MIB RFC 2863, entries created by 
                createAndWait(5) are temporarily created to
                clone parameters.
</edo>
> 2. A status transition from active(1) to notInService(2)
> or destroy(6) is not permitted.

??? So how DOES one get rid of these things???
<edo>

By definition an entry with status active(1) is the extension if IfTable
For interfaces ifType 129 or 205 - regular ifTable extension-
Those are not deleted since are hardware dependant nor created by users,

Only the non-related to ifTable interface entries ( used for clonning) 
are created with CreateAndWait and the rules 4 and 5 apply

             4. Temporary inactive rows must be created using
                createAndWait(5).
             5. The only possible status change of a row created using
                createAndWait(5) (i.e. notInService(2)) or notReady(3) 
                is to destroy(6).
</edo>

> 3. ifAdminStatus from the Interface MIB RFC 2863 should be used to 
> take an Upstream Channel offline.

I assume you mean "SHOULD".  What other mechanisms
can take an Upstream Channel offline?
<edo>
Should replaced by SHOULD
No other SNMP mechanism is defined explicitely,
If I understood your request from the possibility of
docsIfUpChannelStatus = notInService(2)
Upstream channels docsIfUpChannelStatus only reports active(1)
</edo>

> 4. Temporary inactive rows must be created using createAndWait(5).

I think you mean "MUST".  The conformance material
should reflect that the value createAndGo is not permitted.

<edo>
Changed for MUST

The current compliance statement is hard to build since the Flavor (US
channel interface vs Cloning entry)
Is the one with different connotation
IfEntry extension read active(1)
No ifEntry extension: CreateAndWait(5), destroy(6) write

For docsIfBasicComplianceV2 MODULE-COMPLIANCE

Current:
OBJECT  docsIfUpChannelStatus
        MIN-ACCESS  read-only
        DESCRIPTION
            "Read-create in Cable Modem Termination Systems,
             read-only in Cable Modems."

Proposed:

OBJECT  docsIfUpChannelStatus
        SYNTAX       RowStatus (active(1), notReady(2))
        WRITE-SYNTAX RowStatus (CreateAndGo(5), destroy(6))
        MIN-ACCESS  read-only
        DESCRIPTION
            "Read-create in Cable Modem Termination Systems,
             read-only in Cable Modems.
             Entries associated to upstream channels entries in ifTable
             only support read-only value active(2)
             Entries used for cloning purposes supports values
notReady(2)
             createAndGo(5) and destroy(6)."
</edo>
> 5. The only possible status change of a row created using
> createAndWait(5) (i.e. notInService(2)) or notReady(3)
> is to destroy(6).

So how does it get to be active?  (see number 2 above)
<edo>
Never goes active, created entries are used d only as a buffer
for copying values from an upstream channel, modify them and update 
The same or other operational interface.

In RFC 2670 docsIfUpChannelEntries where read-write with optional 
read-only ( no row status), just simple extension of IfTable which are
Vendor dependant configured this extension entries are by default
"always"
Active(1)
</edo>

> 6. Temporary created rows must never be given the status active(1).

I have trouble reconciling this with 2 above.  In general,
this is a *very* confusing DESCRIPTION.

<edo>
Item 2 is for the ifTable entries extension (physical upstream channel
entries) 
not for the user created entries 
Will the proposed text plus  the Object compliance makes that a bit
clear?
</edo>

> A Mandatory procedure for adjusting an specific physical Upstream 
> channel is:

why is "mandatory" capitalized?
<edo>
Typo, fixed
</edo>

> 1. Create a temporary row through an SNMP SET using createAndWait(5). 
> Use an ifIndex value outside the operational range of the system.

How is the "operational range" determined?
<edo>
Out of scope, as the design was concern, you will point with all reasons
that is not 
Good for interoperability 
Will be a scalar with a suggested initial value an option?  
it will goes beyond the closed for additions as we stand rigth now.
</edo>

> 4. Update the physical row by setting the object docsIfUpChannelUpdate

> to true(1). This operation fails with error genErr if the adjusted 
> parameters are not compatible with each other.

My reading of RFC 3416 section 4.2.5 (10) is that inconsistentValue
would be more appropriate.
<edo>
I read inconsistenValue as values that in other circumstances will be
valid, 
e.g setting to a row while active returns inconsistentValue error but if

the row is set to 'notInService' same set will success (RowStatus
constrains).
Here we had the problem that DOCSIS PHY parameters are broad and some 
implementation MAC and or PHY may not support the whole range,  
for that cases the vendor should be able do document the 
AGENT-CAPABILITIES for the implementation version or model
</edo>

> 5. Delete the temporary row through an SNMP SET using 
> DELETEdestroy(6). Temporary entries need not persist at 
> reinitialization of the managed system."

Optional persistence isn't helpful for interoperability.  In this
particular case, it sounds like persistence would be inappropriate,
particularly given RFC 2579's page 16.
<edo>
Will be better to mandate non-persistence?
In any case temporary entries have no operational or configuration
meaning after the cloning process 
is completed,  
Perhaps:

 "Temporary entries SHOULD NOT persist at 
         reinitialization of the managed system."
</edo>
...

> CHANGE #6
> docsIfQosProfileEntry OBJECT-TYPE
...
> An entry in this table must not be removed while it is

MUST NOT?

<edo>
done
</edo>

> An entry in this table should not be changeable while

SHOULD NOT?

<edo>
done
</edo>

> it is referenced by an entry in docsIfCmtsServiceTable.
> If this table is created automatically, there should only

SHOULD?

> be a single entry for each Class of Service. Multiple
> entries with the same Class of Service parameters are not 
> recommended."

NOT RECOMMENDED?

<edo>
By the way, old text from RFC2670, 
can be updated to say "NOT RECOMMENDED"
<edo>
...
> MIN-ACCESS read-only for docsIfDownstreamChannelTable implies the 
> minimal implementation has no persistent requirement. Persistence 
> makes sense only in the case of MAX-ACCESS read-write support.

I don't understand how you come to this conclusion.

<edo>
docsIfDownstreamChannelTable are configuration parameters, if SNMP is
read-only by compliance, 
persistente IMHO is not a feature, Either the system uses defaults upon
reboot or the system 
gather the parameters from a config file. (which is persistent but
outside the scope of SNMP)

Requiring persisntece now will be a new requirement, for DOCSIS not in
RFC 2670 nor DOCSIS spec. 
which should be considered for further work or send back the draft to
IPCDN group discussions for approval.
</edo>
...
> CHANGE # 7
> docsIfDownstreamChannelEntry OBJECT-TYPE
...
> The CMTS ability to retain SNMP SETs for read-write values after 
> system reinitialization is implementation dependant."

This is what StorageType is for.
<edo>
There is no read-create object for this table, it is also a ifTable
extension (for downstream interfaces ifType 128)
</edo>
...
> CHANGE # 8
> docsIfCmtsMacEntry OBJECT-TYPE
...
> The CMTS ability to retain SNMP SETs for read-write values after 
> system reinitialization is implementation dependant."

This is what StorageType is for.
<edo>
Same as above, setting persistence requirements will require IPCDN group
to discuss and aprove that.
</edo>

> docsIfCmtsServiceTable
> Object docsIfCmtsServiceAdminStatus is read-write, and indicates the 
> administrative Status of an active CM upstream queue service, upon 
> reboot all

The ", upon" should be ".  Upon"
<edo>
Ok,
</edo>

> queues are deleted and CMs will re-register. Persistence is not 
> needed. The

One sentence appears to prohibit persistence, and the following sentence
says it's optional.  I prefer the former over the latter.
<edo>
Ok, 
queues are deleted and CMs will re-register. Therefore, persistence does
not apply
</edo>

> docsIfCmMacTable
> This is a CMs specific object.
> docsIfCmRangingTimeout MAX-ACCESS is read-write with DEFVAL clause. It

> is believed that the presence of the DEFVAL and the MIB object 
> reference to the spec is sufficient to not detail CM persistent 
> requirements.

I'm unable to parse this sentence.

<edo>
Will explore that a little bit more
</edo>
...

Randy

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 13 Apr 2004 21:12:33 -0700

Hi -

Thanks Edo for the patient response!  More inline below.

> To: "Randy Presuhn" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, April 13, 2004 6:25 PM
> Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10)
...
> a) or b) will be my options, I started with a) due the b) implications.

I, too,  dislike option (c).
I dislike option (a), particularly if the interoperability difficulties are
not merely theoretical.
I think there are at least three ways of accomplishing (b):
    - using the DESCRIPTION clause to mandate persistence behaviour
    - adding a (potentially read-only) StorageType to the row to
      indicate whether the information there will persist
   - adding a read-only scalar object to the MIB that reports
      whether  the table persists.

...
> Not sure how (a)is put in context,  docsIfCmtsModChannelType is a

In some environments, SNMP is not the only possible configuration
mechanism.  For example, a CLI or netconf might be used to modify
configuration data.

...
...
> Agree, Although text current text was discussed discussed in the IPCDN list

Since you're dealing with installed base, I'm not suggesting you change the
way it works (if it has in fact proven to be interoperable).  My comment is
just that to the non-expert, this "clone-to" mechanism seems really bizarre.
I could suggest much simpler ways to accomplish the goal, but that would
not help maintain compatibility.

> Those are not deleted since are hardware dependant nor created by users,

So, If I understand correctly, these things cannot be provisioned: one must
wait for the hardware to be installed before doing any configuration, rather
than setting up the parameters in advance.

> are created with CreateAndWait and the rules 4 and 5 apply

I'd be nice if the distinction between these two entry types was made
clearer.

...
> Upstream channels docsIfUpChannelStatus only reports active(1)

It might be better to avoid the question by replacing "should be" with "is".  :-)

...
> No ifEntry extension: CreateAndWait(5), destroy(6) write

This explanation was most helpful.  I think your proposed
explanation would be useful, but that it probably should go
into BOTH the OBJECT and OBJECT-TYPE.

...
> "always" Active(1)

Oh.  This "clone-to" stuff is new.  I'm sorely tempted to propose a
much tidier (I think) way to do it, but I don't wan't to be unduly disruptive
at the -10- draft stage of work.

...
> Will the proposed text plus  the Object compliance makes that a bit

Your patient explanations make the intent much clearer.
Thanks.
That doesn't mean that I like it.  :-)

...
> it will goes beyond the closed for additions as we stand rigth now.

One of the things one would hope to avoid is that a newly inserted interface
gets a number that a management system is about to use for cloning.  It's
also hard to imagine how one could configure VACM to give different users
access to different interfaces with this sort of scheme.  This scheme also
wouldn't provide any help at all in avoiding collisions (direct or indirect).
(Two managers try to use the same row for clone-to, or worse still, two
managers use different rows to clone-to the same interface.)

The simplest thing that comes to mind, if I understand the requirements
correctly, would be to put all the clone-to stuff into an AUGMENTS table,
with a simple row "update" button to cause changes to be applied.
That way it would be trivial to ensure that the access rights were properly
restricted.  However, I haven't been in on the discussion and the use cases,
so I'm not making a proposal.  For example, a "profile" mechanism might
be a better fit.

...
> AGENT-CAPABILITIES for the implementation version or model

Fine, but I still believe that inconsistentValue would be the correct return.
Beyond what RFC 3416 says, take the example of RowStatus from RFC 2579.
In the state chart and notes on pages 9 and 10, the case most analogous
to this is setting the status to "active" in state "b".  The intent of "genErr"
was as a catch-all for truly pathological cases.  As I see it, this isn't one of them.

> Will be better to mandate non-persistence?

That would be fine with me.

> meaning after the cloning process

All the more reason for them to not persist.

>         reinitialization of the managed system."

I'd prefer MUST.  Otherwise, RowStatus really isn't the right thing
to use here.  (One could argue that it isn't anyway.)

...
> outside the scope of SNMP)

I disagree with this reasoning.  It is perfectly reasonable for read-only
management information to be persistent.  An example would be a
log entry.  It is also perfectly reasonable for read-only information to
be ephemeral.  A time-of-day clock would be an example.

> IPCDN group discussions for approval.

My comment is simply that the document needs to be clear, and that
preventing a management system from being able to predict whether
a managed device will be able to remember a configuration is probably
not good for interoperability.  Presumably the members of the WG
know whether:
   - there has been any consistency among implementations here
   - whether interoperability has been impaired by this degree of freedom

...
> extension (for downstream interfaces ifType 128)

There is no need for there to be any writeable objects in a table
with a StorageType object.  One could also use a "capabilities"
object outside the table to report whether this information can be retained.
For an example of total over-engineering, one could have a single read-only
BITS object with one bit for each of these tables, reporting whether the
implementation maintains the data persistently.

...

Randy