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

[Jeff Case <[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