Subject: [ipcdn] RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt

From: "Eduardo Cardona" <[email-masked]>
Date: Tue, 2 Mar 2004 10:04:05 -0700

Randy, 

Few comments, 

I review the MIB and appears compelling respect to previous RFC 

Just one comment

(*) traceRouteCtlMiscOptions 
It appears to me an uncanny object and rather implementations may opt to
extend the capabilities in the private branch, could leave with that to
avoid deprecation, of if there are field implementations. 

Regardless of the additions to the MIB I apologize for the late notice,

Before sending a complete proposal and get your concept of the best
approach, below is the proposal  to add a simplified Compliance
statement for devices not requiring to keep constant status of
PING/TRACEROUTE operations, only remote operation per operator request.

We are looking at your comments about the clear overlap in
draft-ietf-disman-remops-mib-v2-01.txt
With IPCDN draft
http://www.ipcdn.org/drafts/draft-ietf-ipcdn-cable-gateway-tools-mib-00.
txt ( currently out of date in IETF drafts site) which is clearly a
subset of the DISMAN-PING-MIB 
Lectors refer to
http://www1.ietf.org/mail-archive/working-groups/ipcdn/current/msg00818.
html

Should the proposal below being include in the remops MIB or should we
update IPCDN cable gateway Tools MIB module to be just the compliance
statement outlined below? 

RFC 3014 (LOG-MIB) introduces the concept of "named log" and "null named
log" default entry for devices not supporting the named log 
Named log is analog to disman remops draft for "OwnerIndex" and
"TestName"  where default entries are created
(null owner, null TestName) for a manager requested operation of PING/
TRACEROUTE, NSLOOKUP, mostly for small foot-print devices with no
network monitoring role at the connectivity level as pretended with this
updated RFC.

In summary A new Compliance Statement for small devices with no
monitoring capabilities to :
 1) remove the constant pulling and login information 
 2) remove the test row creation 
     - CTL* Results* tables only default entries (null owner, null
TestName)
 3) History* tables not required.
	- New basicGroups to exclude History* objects and other objects
which are not relevant to the simplified 
        system. 
      - Create an additional set of Compliance statements to require the
new Groups and other objects Compliance 
        requirements MIN-ACCESS clauses mainly

Schema of the content of the new Compliance statement: 

 List of objects not to include in basicPingGroup OBJECT-GROUP clause
qnd/or hints for OBJECT Compliances:
  pingMaxConcurrentRequests -- remove
  pingCtlDataFill           -- remove or MIN-ACCESS read-only default
value is OK
  pingCtlFrequency          -- remove Only one test
  pingCtlType               -- remove or MIN-ACCESS read-only
  pingCtlByPassRouteTable   -- remove or MIN-ACCESS read-only
  pingCtlDSField            -- MIN-ACCESS read-only
  pingCtlStorageType        -- remove 
  pingCtlRowStatus          -- SYNTAX RowStatus (notReady(2)
WRITE-SYNTAX RowStatus (active(1), notInService(3)  
  pingCtlIfIndex            -- not to include
  pingProbeHistory*         -- not to include.

  List of objects not to include in basicTraceRouteGroup OBJECT-GROUP
clause and/or hints for OBJECT Compliances:
  traceRouteMaxConcurrentRequests  -- remove
  traceRouteCtlType             -- remove or MIN-ACCESS read-only
  traceRouteCtlDSField          -- MIN-ACCESS read-only
  traceRouteCtlByPassRouteTable -- remove or MIN-ACCESS read-only
  traceRouteCtlIfIndex          -- not to include
  traceRouteCtlMiscOptions      -- not to include
  traceRouteCtlDontFragment     -- remove or MIN-ACCESS read-only
  traceRouteCtlInitialTtl       -- remove or MIN-ACCESS
  traceRouteCtlFrequency        -- remove only one test
  traceRouteCtlDescr            -- remove
  traceRouteCtlCreateHopsEntries -- remove HopsEntries not required.
  traceRouteCtlRowStatus        -- SYNTAX RowStatus (notReady(2)
WRITE-SYNTAX RowStatus (active(1), notInService(3)  
  traceRouteCtlStorageType      -- remove
  traceRouteProbeHistory*         -- not to include.

  List of objects not to include in basicLookupGroup OBJECT-GROUP clause
and/or hints for OBJECT Compliances:
  lookupMaxConcurrentRequests   -- remove
  lookupPurgeTime               -- remove
  lookupCtlRowStatus            -- SYNTAX RowStatus (notReady(2)
WRITE-SYNTAX RowStatus (active(1), notInService(3)  

Best Regards

Eduardo

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Monday, March 01, 2004 6:44 PM
To: [email-masked]
Subject: RE: [Disman] WG last call on
draft-ietf-disman-remops-mib-v2-01.txt

Hi -

> From: Eduardo Cardona <[email-masked]>
> Sent: Mar 2, 2004 9:25 AM
> To: Randy Presuhn <[email-masked]>, [email-masked]
> Subject: RE: [Disman] WG last call on 
> draft-ietf-disman-remops-mib-v2-01.txt
...
> One simple note, I tough last call was March 5th

No, it was supposed to end March 2.  However, I'm not
going to hand it to our AD until I can be reasonably sure
that it has received adequate review.

> We at Cablelabs are interested in adding a simplified compliance 
> statement for ad-hoc procedure call instead of a user entry schecule 
> entry, so an user can do a one time execution e.g PING

It would have been nice to have learned of this earlier, rather than
during WG last call.

> The draft we had is almost complete,
> Would be that an opportunity to add that? I can post that tomorrow in
> the list if compeling 
...

I'd like to have this discussion sooner rather than later, so please
make
your specific proposal as quickly as you can.  My opinion as a technical
contributor is that the case for these changes would need to be fairly
compelling if they would result in the remote operations MIB cycling
at proposed rather than advancing to draft standard.  As working group
chair, I want to ensure that whatever course we take reflects WG
consensus.  So, balancing the need for bringing this to a conclusion
with
the need to ensure that the technical issues are properly considered,
I'll entertain discussion of this issue ("ad hoc procedure call") until
Friday noon (Korean Time).  Shortly thereafter I'll make a call on
whether there is consensus to modify the draft regarding this specific
proposal.

Randy

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

---

From: Randy Presuhn <[email-masked]>
Date: Wed, 3 Mar 2004 09:11:49 +0900 (GMT+09:00)

Hi -

> Sent: Mar 3, 2004 2:04 AM
> Cc: "Ipcdn List (E-mail)" <[email-masked]>
> Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt
...

Thanks for the comments!

...
> avoid deprecation, of if there are field implementations. 

any suggested changes?

...
> statement outlined below? 

Both seem reasonable.  If we can include a "basic" compliance statement
to suit your needs without jeopardizing progression, that seems like
an option that I would prefer as a technical contributor, though I
admit that it is not a strong preference and would like to hear other
opinions.

> network monitoring role at the connectivity level as pretended with this

I have no problem with this in principle, and think it would be
really nice if we can verify that the MIB definitions do not preclude
operating this way.

...

I'd phrase it a bit differently.  Rather than "remove" information,
I think the proposal is to ensure that it can function meaningfully using
a small subset of the objects.

I'd like to hear from Juergen (and others) regarding the details of the proposed
compliance material, especially with regard to whether there are
any details in the current object definitions that would prevent this usage.

Randy

---

From: "Eduardo Cardona" <[email-masked]>
Date: Fri, 5 Mar 2004 09:41:03 -0700

Thanks for the comments, 
I will wait as you for hearing from authors
One note below

...

any suggested changes?

In the revision history : ( if option is deprecation), something like 
The MIB object traceRouteCtlMiscOptions is being deprecated,
implementations willing to extend the traceRoute functionality with
proprietary parameters can follow standard procedures of extending entry
tables (e.g. AUGMENTS  [RFC2578])

If willing to have a direct parameters reference in the CTL entry,
similar to the existing traceRouteCtlMiscOptions, uses a new object with
RowPointer syntax or an ID pointing to a private table entry,
( in some cases it may simplify the configuration model if the vendor
feature is just a flag or a common parameter set for all
owners/testNames, pointing the test to the same parameter definition,
policy, etc.
  
As I said, it seems to me to be quite unusual object definition, Due the
already RFC status could be left as is, or change it for one of the
above options or any other alternative. 

Eduardo

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Tuesday, March 02, 2004 5:12 PM
To: [email-masked]
Cc: Ipcdn List (E-mail)
Subject: RE: [Disman] WG last call on

Hi -

...

Thanks for the comments!

...

any suggested changes?

...

Both seem reasonable.  If we can include a "basic" compliance statement
to suit your needs without jeopardizing progression, that seems like an
option that I would prefer as a technical contributor, though I admit
that it is not a strong preference and would like to hear other
opinions.

> RFC 3014 (LOG-MIB) introduces the concept of "named log" and "null 
> named log" default entry for devices not supporting the named log 
> "TestName"  where default entries are created (null owner, null 
> TestName) for a manager requested operation of PING/ TRACEROUTE, 
> NSLOOKUP, mostly for small foot-print devices with no network 
> monitoring role at the connectivity level as pretended with this 
> updated RFC.

I have no problem with this in principle, and think it would be really
nice if we can verify that the MIB definitions do not preclude operating
this way.

...

I'd phrase it a bit differently.  Rather than "remove" information, I
think the proposal is to ensure that it can function meaningfully using
a small subset of the objects.

I'd like to hear from Juergen (and others) regarding the details of the
proposed compliance material, especially with regard to whether there
are any details in the current object definitions that would prevent
this usage.

Randy