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

[[e-mail]]

> 
> 
> sorry to have to send this from my account at the university ... ever
> since we opened speedbump up to anonymous ftp, there have been unexplainable
> things happening to that machine (and others behind it)  ... we are working
> with cert to explore the causes ... so, in the meantime, i'll post this
> message from here
> 
> please send all replies to the list or to [e-mail]
> 
> thanks
> 
> -----
> 
> 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
> 
> 
> 
> >    - 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
> 
>     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
> 
> 
> CONCLUSION:  This is not new stuff that has heretofore never been discussed
>              in public
> 
> 
> 
> >    - 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.
> 
>     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
> 
> 
> 
> CONCLUSION:  This is not new stuff that has heretofore never been discussed
>              in public
> 
> 
> 
> >    - "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
> 
> 
> 
> >    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
> 
> 
> 
> >    - 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
> 
> 
> 
> 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 
> 
> 
> -----------------------------------------------------------------------------
> 
> DISCUSSION:
> 
> 
> i have responded to the technical content of your note, but have chosen not to
> respond at this time to the increasing frequency and boldness of the
> vindictive attacks contained in your recent notes, including this one 
> 
> for the best interests of the Working Group, i am continuing to resist the
> temptation to respond in kind to your rude jabs ... the Working Group doesn't
> need nor want to hear that kind of dialog and i'm trusting that they'll 
> appreciate my restraint as a sign of strength rather than a position of
> weakness ... so i don't intend to stoop to your level by responding to
> these attacks
> 
> 
> if i properly understand your tactics, you are attempting to manipulate the
> Working Group by making certain claims about the synthesis documents
> 
> you claimed (again, using your own words (so as to not be accused of putting
> my spin on them):
> 
>     "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."
> 
> it is my understanding that you hoped that through these declarations, you
> might be able to get the synthesis rejected, no matter how meritorious it
> might or might not be
> 
> you challenged me to refute these claims, which i have done, with
> documentation
> 
> 
> yours might have been an effective tactic for manipulating the working group
> except for one detail ... your claims are unfounded and without basis
> 
> 
> META CONCLUSION:  Your tactic has failed.  Your best and only point is the 
> choice of type for the index on the view table, and i can't imagine you'd be
> so foolish as to attempt to pin your hopes on such a weak point
> 
> 
> 
> we'll save the discussion of the merits of the ideas for another note and
> limit this one to the legalistic claims you have made about the items you
> identified in the synthesis ... the discussion of the technical merits can
> be the topic of another note 
> 
> one final thought before closing:
> 
> we've processed this list as if it were the list that our chairman, bob,
> tasked you to prepare although it isn't clear if you meant it to be so in
> that the message was addressed to aleksey ... since you aren't yet heeding
> other instructions in that message, perhaps you haven't seen it yet or perhaps
> your messages might have crossed in transit
> 
> in either event, we will respond to any additional items you may wish to
> raise once you've taken the time to read the documents beyond the "cursory
> examination" you cite thus far ... perhaps if you take the time to read the
> synthesis, you'll even like it
> 
> 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
> 
> 
> if you'd like to help by point out the text which you find difficult to 
> understand, please do so ... we merely request that you do so with substantive
> technical arguments which back up your assertions without all the emotional
> glop
> 
> of course, you'll need to ask a complete question ... researching and
> preparing a thoughtful and courteous response to your list has consumed time
> and this time was unnecessarily long because of your vague assertions ... so,
> complete questions or comments are essential
> 
> now, can we get back to substantive technical discussions?  without all the
> emotions?
> 
> thanks in advance
> 
> regards,
> jdc
>