Subject: [Isms] [[email-masked]: I-D ACTION:draft-schoenw-snmp-discover-00.txt]

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 13 Dec 2006 22:23:59 +0100

Hi,

I started an ID concerning engineID discovery. There was some
discussion about this topic in the ISMS working group in the past and
recently there was a thread on the "netconf goes on" (ngo) mailing
list <[email-masked]>.

ISMS is not really chartered to work on general engineID discovery.
However, any real-world ISMS implementation needs to figure out a way
how to do engineID discovery. The approach documented in the ID does
provide a general discovery mechanism which has the benefit that it
does not need any modifications to existing SNMPv3 standards (as far
as I understand things).

I am looking for review, feedback, criticism and suggestions. If we
manage to find agreement on an approach, I am sure we can talk to the
various ADs how we can best move this forward. Lets get a solution
worked out first.

Since the ISMS list is not really busy and since ISMS implementations
kind of need engineID discovery to be acceptable in practice, I think
it is fine to host further discussions here on this list (and I expect
that a sufficient number of SNMP experts are following the ISMS list
anyway).

/js

----- Forwarded message from [email-masked] -----

To: [email-masked]
Cc: 
From: [email-masked]
Date: Wed, 13 Dec 2006 15:50:06 -0500
Subject: I-D ACTION:draft-schoenw-snmp-discover-00.txt 
Precedence: list
Reply-To: [email-masked]
Errors-To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: Simple Network Management Protocol (SNMP) EngineID Discovery
	Author(s)	: J. Schoenwaelder
	Filename	: draft-schoenw-snmp-discover-00.txt
	Pages		: 8
	Date		: 2006-12-13
	
   To retrieve management information using the third version of the
   Simple Network Management Protocol (SNMP), it is necessary to know
   the identifier of the remote SNMP protocol engine.  This document
   introduces a discovery mechanism which can be used to learn the
   engine identifier of a remote SNMP protocol engine.  The proposed
   mechanism is independent of the features provided by SNMP security
   models and may be used also by other protocol interfaces to discover
   the engine identifier.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-schoenw-snmp-discover-00.txt

[...]

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

---

From: Joe Fernandez <[email-masked]>
Date: Thu, 14 Dec 2006 18:05:09 +1100

Hi,
At 10:23 PM 13-12-06 +0100, Juergen Schoenwaelder wrote:

>I started an ID concerning engineID discovery.

>I am looking for review, feedback, criticism and suggestions.

I have one major question and a few minor ones that are numbered below.

The question is about registration and Abstract Service Interfaces.

RFC 3411 calls itself an architecture for *describing* SNMP Management 
Frameworks and I take this to mean it should not be interpreted as the 
*required* architecture for *implementing* SNMP Management Frameworks.

The standard specifies what goes on the wire, not what goes in the box, 
right? Designers can consent to their modules doing different things in the 
privacy of their own nodes.

RFC 3411 introduces ASIs and says they  "are intended to help clarify  the 
externally observable behavior of SNMP entities, and are not intended to 
constrain the structure or organization of implementations in any way."

The ASIs introduce the concept of applications registering responsibility 
for contexts.

With this background, my question is whether your procedure which seems to 
specify that applications have to register in a particular way, is 
constraining the implementation in a way that was not originally intended.

It seems to me that the alternative of recognizing a local context constant 
does not unduly constrain the implementation to the ASIs.

As part of this question, I would like to ask David Harrington: With 
reference to your recent posting in which you described the ASIs as highly 
unpopular, can you say with whom they are unpopular and why?

Minor questions:

1.
Section 3.1 says "To facilitate discovery, it is assumed that SNMP agents 
register their snmpEngineID scalar using a special well known 
contextEngineID.".

I find the wording  - "assumed"  - odd.

Don't you need to say something along the lines: This 
(standard/specification/whatever) requires an SNMP agent to register its 
snmpEngineID using a special well known contextEngineID, which is defined 
later in this document and/or the SNMP Framework MIB."  or "..an SNMP agent 
MUST register....." ?

2.
Section 3.1 says that agent implementations MAY register other objects with 
the localEngineID but managers should not count on it. How does the manager 
discover which way the implementer has chosen to go (short of trial and error)?

3.
I know what your pseudo code is meant to do because we have discussed it 
(at some length :-)  ) But isn't a new reader going to be baffled by the 
code first setting contextEngineID to the localEngineID constant and then 
immediately again setting it? There's no ASI here to tell the reader that 
the constant is used in the Get. I suggest that you may want to add 
comments to this block of pseudo code.

4
Assorted editorial:
4.a
Section 1:   To retrieve management information using the third version of the
    Simple Network Management Protocol (SNMPv3) [RFC3410], it is
    necessary to know the identifier of the remote SNMP protocol engine.

engineID is also needed for setting.

4.b
Section 3: when you say " ..require the snmpEngineID scalar" do you mean 
"request" or "acquire",  perhaps?

4.c.
Section 3.1
Some of the references to "agent" may need to be "command responder 
application"  - ?

4.d
Section 4.
Thank you for the generous acknowledgement. It seems curmudgeonly to offer 
a correction but since we have been warned of the problems with using slang 
and idiom, I'll suggest you may want to replace "Fall 2006". "Fall" in this 
context is not exactly slang or idiom but I think it only has a localized 
meaning. In any case, it is summer here in Sydney. I'll suggest "December 
2006" as a *quick fix*. If this gives you an opportunity to respond with an 
*architecturally elegant* solution that decouples the reference from the 
Gregorian Calendar, I'm going to regret ever mentioning this :-).

Joe Fernandez
Kardinia Software
[email-masked]
www.kardinia.com

---

From: "David Harrington" <[email-masked]>
Date: Thu, 14 Dec 2006 10:59:57 -0500

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email-masked]] 
> (and I expect
If they are, I will admit my surprise at their ability to remain
absolutely quiet.

dbh

---

From: "David Harrington" <[email-masked]>
Date: Thu, 14 Dec 2006 12:33:30 -0500

Hi,

**********************************************************************
*** 
This is an unofficial bulletin from the SNMP architectural purity
police 
**********************************************************************
***
 ;-)

I haven't been following the NGO threads closely over the last two
weeks and have not yet reviewed Juergen's draft.

So let me only address Joe's question, out of context.

> *required* architecture for *implementing* SNMP Management
Frameworks.

That is correct. The RFC3411 architecture is not meant to constrain
implementations.

> constrain the structure or organization of implementations in 
That is correct.

The title of RFC3411 very deliberately used "An Architecture" and "for
Describing". The primary purpose of the architecture is to develop a
modular standard in order to create a consistent terminology for
discussion of the conceptual components of an SNMP entity, and the
conceptual data flows that occur between the conceptual components to
ensure that the right information gets to the pieces that need it.

A second purpose of RFC3411 is to make SNMP extensible - to clearly
define a minimal set of data-flow dependencies between conceptual
subsystems, to make it easier to propose extensions to different
portions of the standard within the IETF standards process. Prior to
RFC3411, extensions to SNMP pretty much required opening up the whole
monolithic standard.

It had become clear that different segments of the industry have
different needs that could be addressed using extensions to certain
portions of the SNMPv3 standard, and that the IETF was unlikely to
ever reach consensus on a single specification that met everybody's
requirements for different transports, message formats, message
security, and data access controls.  

That trend has continued, and the IETF Management Framework is being
opened to using not only different extensions to SNMP, but even
non-SNMP protocols are being accepted as part of the IETF management
solution.

> unpopular, can you say with whom they are unpopular and why?

There are only two groups who really are impacted by the ASIs -
implementers and standards developers.

Despite the fact we tried to put disclaimers all over the place that
the ASIs were about describing minimal conceptual data flows between
conceptual subsystems, and not about constraining implementations, and
that the ASIs are NOT APIs, the format of the ASI looks like an API,
and implementers who tried to implement them as APIs really disliked
them. Some implementers disliked the whole conceptualization of
subsystems, because it didn't match their implementation, and it
became a bit harder to translate the concepts from the standardized
modular architecture to their existing implementation architectures. 

I would have much preferred to use data-flow diagrams (DFDs) in the
document to model the flows of data, but we are constrained to
70-column ASCII in IETF documents, and that format does not lend
itself to DFD notation. So we chose the current ASI format, which was
easily understandable because it looked like a function call.

Standards developers disliked it for a different reason. The RFC3411
"descriptive" architecture has become a Full Standard and part of the
IETF Standard Management Framework, and it is widely interpreted as
the *required* architecture for *designing* IETF-standard SNMP
Management Frameworks. 

To a degree, it stopped being descriptive and became prescriptive
(Thanks, Bert for the nice choice of words). But not exactly - the
IESG has not mandated RFC3411 as the required architecture for
designing IETF-standard SNMP Management Frameworks (unless a WG agrees
to it during charter discussions).

The "descriptive" architecture standardized the terminology and
concepts to discuss design decisions and proposed extensions. If
somebody makes a proposal to modify/extend SNMP that uses different
terminology and concepts, the members of the IESG are likely to
question why the proposal is done using non-standard terminology and
concepts. 

David Harrington
[email-masked] 
[email-masked]
[email-masked]

---

From: Joe Fernandez <[email-masked]>
Date: Fri, 15 Dec 2006 14:22:40 +1100

Thanks for the detailed and lucid explanation.

>Hi,

So is there a Captain Architecture whose responsibility it is to remain 
vigilant against the threat of QAPDFs (Quick And Possibly Dirty Fixes) and, 
when he/she sees a proposal for one, to take up his/her cape and Design 
Patterns handbook  and leap into battle for elegance, modularity, and the 
IETF way?

:-)
Joe Fernandez
Kardinia Software
[email-masked]
www.kardinia.com

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 15 Dec 2006 08:44:29 +0100

> constraining the implementation in a way that was not originally intended.

No. We usually describes things in our architectural framework with
the understanding that implementations may choose different ways to
achieve the same behavior. In terms of the NET-SNMP code base, I think
the actual code change to support the "local" engineID is in the order
of roughly 5 lines of code since the registration is kind of hard
wired.

> does not unduly constrain the implementation to the ASIs.

Not sure what you mean here.

> unpopular, can you say with whom they are unpopular and why?

Well, you asked Dave, so I should probably not respond. Personally, I
think there are two main reasons why ASIs are sometimes unpopular:

(1) People often confuse the ASIs with APIs. The ASIs are conceptual in
    order to understand the information flow within an SNMP engine and
    to avoid side effects. Implementations often use a different structure
    for various reasons and that is just fine.

(2) The ASIs are rather precise in defining what data flows where
    compared to many other IETF protocol standards. This level of
    precision was actually needed when the ASIs were introduced
    because the reuse of data items in various parts of what we call
    an SNMP entity these days did lead to all sorts of problems. Of
    course, this level of detail makes it also much harder to talk
    about extensions since (a) you can't simply leave some nasty
    details to implementors to figure out and (b) the learning curve
    to enter and follow discussions is rather high.
> later in this document and/or the SNMP Framework MIB."  or "..an SNMP agent 

I will fix the wording. 
 
> discover which way the implementer has chosen to go (short of trial and 

To discover the engineID, the other objects are not needed. I believe
managers should simply discover the real engineID and then use the
correct engineID. Agent implementations, however, might find it
simpler to export all objects in the "local" engineID context.

And yes, I do not mind if an application which only needs a single
variable during its short lifetime sends a get(snmpEngineID.0,
something.0) and is prepared to handle any exceptions or failures by
retrying. I believe this is implementation choice.

> comments to this block of pseudo code.

I will try to rewrite the pseudo code and add more comments. Perhaps I
should introduce a "session" handle which is modified and passed
around, as is common in many SNMP APIs I have seen.

> engineID is also needed for setting.

Yes. I will fix this.

> "request" or "acquire",  perhaps?

Will fix the wording. 
 
> Some of the references to "agent" may need to be "command responder 

Yes. I will fix this.
 
> Gregorian Calendar, I'm going to regret ever mentioning this :-).

I will fix this as well.

Thanks for your feedback.

/js

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

---

From: Joe Fernandez <[email-masked]>
Date: Wed, 20 Dec 2006 22:28:47 +1100

At 08:44 AM 15-12-06 +0100, Juergen Schoenwaelder wrote:
[..]
>Not sure what you mean here.

I mean that it seems to me possible to specify support for a local context 
by recognition of a local contextEngineID constant without constraining the 
implementation to take section 4 of RFC 3411 as prescriptive.

If you start with the ASIs in mind as your model, then you tend to be 
driven by thinking along the lines of an application code module 
registering responsibility for contextEngineIDs. But the standard is purely 
to achieve interoperability, right, so its about bits on the wire not code 
in the node.

In practice in most cases there will not be a proxy and in many cases a 
manager will be talking to a single agent that has a single 
contextEngineID. So the manager should have a simple way to tell the agent 
to use its default contextEngineID and gain access to   all objects in the 
named context.

[..]

>     details to implementors to figure out

...perhaps you can, but I'll agree that it is much kinder to provide 
guidance in the form of a possible implementation scenario. The question 
then is when this guidance goes from being descriptive to being prescriptive.

Your proposal explicitly leaves open the possibilities that agents may make 
either just snmpEngineID accessible under this contextEngineID or 
additional objects, which could be "all" objects.

How about defining two well known constants, one for the single object 
case, the other for the all object case? Then if the agent is known to have 
implemented the latter, the manager knows it can access any object in a 
single operation by using the second constant.

If you do not see any objections to this alternative I can draft the text 
for it.

[..]

> > Gregorian Calendar, I'm going to regret ever mentioning this :-).

I hope it was clear that this last comment was meant as a joke and that it 
did not cause any offence.  Email is a deadly medium where attempts at 
humour sometimes go off the rails....

Joe Fernandez
Kardinia Software
[email-masked]
www.kardinia.com

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Dec 2006 00:20:27 +0100

> to use its default contextEngineID and gain access to   all objects in the 

Or the manager simply uses the "real" contextEngineID...

> If you do not see any objections to this alternative I can draft the text 

I strongly dislike adding a second constant to avoid finding agreement
on the scope of a single constant. You did not really say why you want
to require "all" objects under the "local" contextEngineID. Is it
because you want to safe a round-trip time because you can get away
without doing a contextEngineID discovery? Are there other reasons?

And yes, I would love to hear more opinions. Anyone out there
following this discussion?

/js

---

From: Joe Fernandez <[email-masked]>
Date: Thu, 21 Dec 2006 23:12:37 +1100

Hi,

>Or the manager simply uses the "real" contextEngineID...

But in the situation we are discussing the manager does not know what the 
real contextEngineID is. That's why you created  this Internet-Draft on 
EngineID Discovery, right?

So the two options we are discussing are:
a) the manager says "tell me what your engineID is so I can echo it back to 
you and get you to use it"

or

b)the manager says "use your own engineID, whatever it may be "

Option a) seems unnecessarily artificial and roundabout to me.

>on the scope of a single constant.

But doesn't your proposal avoid finding agreement on the scope of your 
single constant, anyway? See my first para of my three paras above......the 
one that starts "Your proposal explicitly.."

>You did not really say why you want

There's a design principle that says something along the lines that a good 
design should be no more complex than it needs to be. It is usually stated 
in a more elegant and simple way than that but I forget what the usual 
statement is.

I think I stated that this was the basis of my objection, in the earlier 
discussion on the NGO mailing list.

I still think that it is because I am not approaching the solution from the 
ASI point of view that I think a simple clean solution is to have the 
manager send a contextEngineID value that means "this" engine (and that is, 
of course, not an original contribution from me.)

>following this discussion?

I am just wondering if I can call this the "You talkin' to me?" problem 
without incurring the wrath of  David Harrington. Before he sends me to the 
sin bin, I want to say that this quote has an entry in Wikipedia that 
anyone on this list can look up, if the quote does not mean anything to them.

The manager engages in an interaction with the agent but does not know the 
agent's engineID

So the agent says "You talkin' to me?" .

We both agree that even though this is not a proxy situation, we do not 
want the agent to go "Well I'm the only one here", but we are still having 
a minor disagreement on what the agent's behaviour should be.

So yes, other views would be good.

Joe Fernandez
Kardinia Software
[email-masked]
www.kardinia.com