Re: a response from dr. snmp on behalf of the snmpv2* team

[[e-mail]]

Hi,

> marshall:
> 
> i am writing to respond to your list of new features and new mechanisms you
> posted late last night in a note to aleksey
> 
> the question on the table is, using your own words (so as to not open myself
> to accusations that i'm putting "spin" on them) as follows
> 
> To what extent is
> 
>     "many of these are major changes to SNMP, none of them are in any of the
>     real proposals; indeed, many have heretofore never discussed in public."
> 
> in fact, true?
> 
> first, the facts about the items in your list: (commentary follows)
> 
> >    new features:
> >    - manager-to-manager communication without either having an agent
> 
>     see draft-ietf-snmpv2-adminv2-ds-02.txt, page 16, definition of a manager
>     see also draft-ietf-snmpv2-proto-ds-01.txt, page 28, near the top
> 
>     both of these documents talk about manager-to-manager communications
>     between two managers ... nowhere is there any clue that one needs to have
>     an agent -- if there was a need to have an agent where is that stated?
> 
>     this is, after all, called a manager-to-manager communication, not called
>     a dual-role entity communication to dual-role-entity communication
> 
> 
> CONCLUSION:  This is not new stuff that has heretofore never been discussed
>              in public

1. I do not think that you are right about it. Old m2m stuff
   assumed that each SNMPv2-Classic entity has seveal MIBs
   implemented: e.g. unprotected access to parties' clock was
   as essentual for synchronization in SNMPv2-Classic as access 
   to similar elements in original USEC.

2. At the same time it is the most significant positive (while trivial)
   contribution of new proposal. BTW, it fits into exisiting USEC
   as a snap, basically by renaming agentID into snmpID.

> 
> 
> 
> >    - multiple auth/priv protocols associated with one user
> 
>     see draft-kzm-snmpv2-adminv2-alt-00.txt throughout ... given that usec
>     admin allows multiple models, potentially multiple user-based models,
>     usec allows a single username to be associated with multiple combinations
>     of model and qos, where qos selects a single auth/priv protocol
>     combination

Exactly, and I would say that 'as all other known admin infrastructures'
can be added to this sentense. 

> 
>     the snmpv2* synthesis is similar in this regard, wherein a single username
>     can be associated with multiple values of sPI where the spi is equivalent
>     to the combination of a usec model and qos ... there is no basic
>     difference between these approaches -- the primary difference is if the
>     two concepts are encoded as two disparate fields or as 1 field which
>     represents the cross product

This is completely different thing. And it is a clear overkill from all
practical points of view.

> 
> 
> CONCLUSION:  This is not new stuff that has heretofore never been discussed
>              in public

So, I do not think you are right about it.

> >    - access control via context bit-masks
> 
>     this aspect of the mib design is a direct result of other design decisions
>     and two are worth mentioning here
> 
>     first, the USEC design shifted the paradigm from having context names
>     in simple agents administratively assigned by a system administrator
>     to a new paradigm wherein context names are administratively assigned
>     by agent implementors, as evidenced by the read-only nature of these
>     entries in the USEC MIB for simple agents ... we agree with this design
>     decision and incorporated it in the synthesis
>
>     however, as a result of this paradigm shift in the design of the context
>     table, it shouldn't be surprising that there are ripple effects in the
>     tables which "point" to the context table since the administrator is
>     no longer in complete control of the configuration
> 
>     this is especially critical in hot-swappable chassis with dynamically
>     loadable contexts.

So, it is a new thing.

>
>     second, see draft-ietf-snmpv2-adminv2-ds-02.txt page 50 near top
>     where it states that every attempt has been made to minimize the amount
>     of NV storage required ... we agree with this design decision and
>     incorporated it in the synthesis

This is a very shaky ground to consider it old :).

> 
> 
> CONCLUSION:  This is not new stuff that has heretofore never been discussed
>              in public

It is not that old (we had only briefely discussed it with Keith) upon
publication of USEC-MIB, but this was the only time I remember this
topic touched.  BWT, it is not absolutely foreign for USEC.  


> >    - "security" based on transport-addresses
> 
>     see draft-kornegay-snmpv2-emf-00.txt, page 4, near the middle and
>     see draft-wijnen-snmpv2-snmpv2t-00.txt, page 6, near the end of the first
>     paragraph of section 2.2
> 
> 
> CONCLUSION:  This is not new stuff that has heretofore never been discussed
>              in public
> 
> 
> 
> >    - MIB-based configuration of community-based authentication
> 
>     see draft-ietf-snmpv2-party-ds-02.txt  page 14, at the top, in
>     conjunction with the bottom of page 20 and the top of page 21 (look
>     for rfc1157noAuth)
> 
>     see also draft-ietf-snmpv2-tm-ds-02.txt page 14
> 
>     i could cite more, but one example should be sufficient, and three should
>     be more than sufficient
> 
> 
> CONCLUSION:  This is not new stuff that has heretofore never been discussed
>              in public
> 
> 
> 
> >    - grouping of transport addresses
> 
>     see draft-ietf-snmpv2-adminv2-ds-02.txt page 50 near top
>     and similar comment above
> 
>     further, chairman bob posted a message to this list on behalf of case,
>     mccloghrie, and rose on Tue, 25 Apr 1995 11:09:26 -0400 containing a
>     proposal for a transportTable which is materially similar to the one
>     found in the synthesis and there were multiple messages discussing
>     this table in the months of april and may, including reports of
>     implementation experience and feedback
> 
> 
> 
> CONCLUSION:  This is not new stuff that has heretofore never been discussed
>              in public
> 
> 
> 
> >    - configuration of access-control (for an existing user) according to
> >      the group a user is in.
> 
>     first, you need to get your terms correct ... the synthesis configures
>     access control according to the group an identity is in, in contrast to
>     configuring according to the group a user is in ... which, for some
>     values of sPI, this identity maps to a username (this is the default)
> 
>     second, there is no requirement in the synthesis that the identity be in
>     existence, there may or may not be an identity in any spi which
>     corresponds to that group ... the synthesis allows a configured set of
>     access rights for a group quite independently of whether there are zero,
>     one, or many identities associated with that group ... this is an
>     important isolation of the authentication from the access control
> 
>     third, this isn't new ... see draft-ietf-snmpv2-scm-ds-01.txt, especially
>     scmUserCapIndex pointing into the scmCapTable
> 
> 
> CONCLUSION:  This is not new stuff that has heretofore never been discussed
>              in public


It still new part. It is not that clear that it is as positive as
context groupping, though.

> >    new mechanisms:
> 
> Most of the "new mechanisms" you cite are bug fixes.  These are fixes to
> bugs identified in the document entitled "Problems with the SNMPv2
> Proposals".  Glenn's posting of 26 Aug 1995 claims that several problems
> are not problems, and we, of course, disagree about this.  Claims that
> problems are not problems is not a solution.  You may reread the relevant
> areas of the previously provided text.
> 
> >    - ASCII-naming of Views 
> 
>     ok, you have us here ... this is our most vulnerable spot
> 
>     we thought that if we are going to move from OIDs for contexts to
>     user-friendly string-based names for contexts, and from parties named by
>     OIDs to user-friendly string-based user names, that it was consistent to
>     also name views by user-friendly string-based view names ... with the
>     hook that in resource poor systems, i.e., those with precious little
>     nvram resources, that the strings can be real short, like one byte,
>     e.g., "1", "2", "3" etc
> 
>     this hardly seems the basis by which one would decide a set of documents 
>     totaling 200+ pages is/is not "new" 
> 
> 
> CONCLUSION:  This is new stuff, but inconsequential, but easily transformed
> back to small-valued integers if the Working Group so desires
> 
> 
> 
> >    - agentID changed to snmpID and the need for a manager to have one
> 
>     bug fix ... see  "Problems with the SNMPv2 Proposal" page 7ff
> 
> 
> CONCLUSION:  This is not new stuff that has heretofore never been discussed
>              in public
> 
> 
> 
> >    - a scopedPDU SEQUENCE to provide naming of (proxy) contexts via snmpID
> 
>     bug fix ... see "Problems with the SNMPv2 Proposal" page 9ff
> 
> 
> CONCLUSION:  This is not new stuff that has heretofore never been discussed
>              in public

I may be one of the bugs in SNMPv2-Classic, but it is definetely 
not a problem for USEC-like stuff. And it never was disccussed in this
context. Yet another different-but-not-better part in this proposal.

> >    - receiver is the authoratitive source of clock for Informs
> 
>     bug fix ... see "Problems with the SNMPv2 Proposal" page 7ff
> 
> 
> CONCLUSION:  This is not new stuff that has heretofore never been discussed
>              in public

There is no such bug in USEC hence this is not a fix, and there was
no discussion on the matter addressing these issues in in USEC-context,
among other things because there is no such issue. Yet another 
different-but-not-better part.


> in the final challenge of your note, you state:
> 
> >further, i might add that the one thing that the "synthesis" non-proposal
> >did manage was to exclude use of public-key technology, i.e., it says
> >
> >
> >    "transmitted on behalf of identity"
> >
> >Given that this is inconsistent with future support of asymmetric
> >cryptography, i'm not sure how the "synthesis" non-proposal can state
> >that all of the proposals had good things in them, when one of these
> >proposals was entirely about use of public-key technology.
> 
>     first, do you really think your repeated attempts to castigate the
>     synthesis with these labels is effective?  it makes you look
>     increasingly desperate
> 
>     second, i have looked in the synthesis documents but cannot find the
>     text you cite ... could you perhaps help me out with that with a
>     document name/title and a page number?
> 
>     third, there is *nothing* in the synthesis that is incompatible with
>     public key cryptography ... if you wish to assert that there is,
>     could you please state the technical grounds for your beliefs?
> 
>     fourth, even after we prove that public-key technology does work, 
>     some readers will continue to be confused by your unsubstantiated 
>     claims.  this is unfair to our synthesis and we respectfully request
>     that you be more careful in the future.
> 
> CONCLUSION:  Like those above it, this assertion is false 

Have no idea about it. I know one thing for sure that pkc support and hence
(as it was said to us) necessity of source parties was one of the things
which killed SNMPv2-Classic. 


> while we'll respond to additional items you may wish to raise, we feel
> it would be a much more worthwhile use of everyone's time and the
> bandwidth on the list to focus on the technical details of the
> synthesis and the merits of the design rather than to waste additional time
> on failed attempts to challenge the legitimacy of the synthesis based on
> some legalistic criteria

Cannot agree more. 

> now, can we get back to substantive technical discussions?  without all the
> emotions?

I would like also see an argument presented wrt what is worth fixing
in USEC beyond unboubtful items. 


1. M2M communication path.
2. Context grouping.


Also, I hope that in case new efforts to public standard of agent extesibility
will be set as part of IETF NM area task (there is a crying need in the
industry) you will not torpedo it on the basis of bad interpersonal
relations with paticipants.

> jdc

Aleksey