Subject: RE: [NGO] MIB Access using Netconf RPCs

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 5 Dec 2006 13:00:57 +0100

> > > I believe we should follow Dave Perkin's suggestion and define a
> > > "this" contextEngineID constant which always means use the local
> > > engineID as the contextEngineID. This would solve the problem for
> > > the non-proxy case for both ISMS and NETCONF or any other
> > > interfaces.
> > 
> > I agree this might work, but we need to determine how to change the
> > existing elements of procedure to support this.
> 
> Section 4.2.2.1. or RFC 3412 says:
> 
>    1) The combination of contextEngineID and pduType is used to
>       determine which application has registered for this request or
>       notification.
> 
> What about this:
> 
> a) We define a "localEngineID" contextEngineID value.
> 
> b) We suggest that the applications handling pduTypes that are "local"
>    to the snmp engine register under this "localEngineID" value (in
>    addition to the usual registration under the contextEngineID).
> 
> Once that has happened, things should just work without any further
> modifications of the elements of procedure. Note that RFC 3412 already
> allows multiple registrations for different engineIDs. Am I missing
> something?
> 

Without having re-read all of the RFC341x related text, I think the above 
may indeed work and be doable.

Bert

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 5 Dec 2006 14:31:32 +0100

> may indeed work and be doable.

I must admit that architecturally having meaningful contextEngineIDs
in the scopedPDU is beautiful and introducing something like a well
known "localEngineID" is not really nice since now the scoped PDU is
implicitely scoped by the SNMP engine processing a message which is
typically identified by a transport endpoint.

I believe some of the IP network and transport layer people would love
to have a proper separation of address spaces and it is irritating
that we have it in the SNMP architecture but it seems most
applications don't want it (likely because they were written before
SNMPv3 came along).

The architecturally cleaner solution would be to support
contextEngineID discovery, much like we have securityEngineID
discovery in USM. However, as far as I understand things, this would
actually imply a small change in the elements of procedures to work.
And so we run into the old problem - do we like to do what is
technically the best solution or do we pay tribute to the standards
process we live in and do what may work, even though it might fire
back on us a few years down the road?

I really have no answer - all I know is that we have a general problem
here which so far was simply hidden because implementations use USM
securityEngineID discovery as a way to discover the contextEngineID.

[Perhaps this thread should move somewhere else (e.g. ISMS) since it
 is really not netconf specific; but it is also unclear whether this
 falls into the ISMS charter, probably not.]

/js

-- 
Juergen Schoenwaelder		 {International|Jacobs} University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

---

From: Andy Bierman <[email-masked]>
Date: Tue, 05 Dec 2006 08:24:22 -0800

Juergen Schoenwaelder wrote:
>....

No.
IMO, this list should be wide open to any ideas and threads
related to NETCONF.  This is related, although only the SNMP
experts know what you're talking about.

> /js

Andy