Re: review draft-ietf-snmpv3-coex-v2-02.txt

HI,

On Friday, February 21, 2003, at 09:53 PM, David Levi wrote:
> >
> > Hi Harrie,
> > > > Abstract
> > > >
> > > >    The purpose of this document is to describe coexistence 
> between
> > > >    version 3 of the Internet-standard Network Management
> > Framework,
> > > >    (SNMPv3), version 2 of the Internet-standard Network 
> Management
> > > >    Framework (SNMPv2), and the original Internet-standard Network
> > > >    Management Framework (SNMPv1).  This document
> > obsoletes RFC 2576
> > > >    [21].
> > >
> > > Just to be clear. It basically speaks about coexistance between
> > > SNMPv1 - SNMPv2, SNMPv1 - SNMPv3, SNMPv2 - SNMPv3. All versions
> > > against the other versions. right?
> > >
> > > I am asking, since
> > > -  for instance, section 1.4 looks like v1 and v2 only (See
> > > there also).
> > > -  the document also describes coexistance between SMIv1 and SMIv2
> > >        where SMIv2 is a seperate standard.
> > >        Is that therefore needed in this document?
> > >        Is SMIv1 and SMIv2 not usefull if that will be added in the
> > > abstract?
> >
> >
> > I wasn't sure what exactly you were asking us to change here.
> >  It sounded
> > like you were suggesting that the parts of the document
> > regarding converting
> > from SMIv1 to SMIv2 be removed and put in a different
> > document.  Can you
> > clarify this?

I was indeed not that clear, I was also stating more a question. IMO, 
the
abstract could be made more precise.
This document not only handles SNMP protocol version differences,
but also SMI version differences. Not that I want to seperate that.
For SNMPv1 the connection to SMIv1 is clear (those go hand-in-hand), but
SNMPv2 and SNMPv3 both have SMIv2 plus the fact that SMIv2 is a seperate
STD58. Therefore, I believe that if SMIv2 is seperated also the abstract
should mention it unless we have to see some version of SMI as an
integral part of some version of the 'Internet-standard Network
Management Framework'.



>
> >
> > > This section 1.4 seems also the be hanging between section 2 and 3.
> >
> >
> > Not sure what you mean here, is there something you thought
> > should change?

What I think is odd is that it all seperates the SNMP protocol
versions nicely and section 1.4 combines 2 versions of SMI. Therefore, 
it
looks like this section is somewhere between section 2 and 3.

What I would do (believe should be done) is drop this section and make 
it
part of section 2.
>
>
> >
> > > > 3.  Translating Notifications Parameters
> > > >
> > > >    This section describes how parameters used for generating
> > > >    notifications are translated between the format used for 
> SNMPv1
> > > >    notification protocol operations and the format used for 
> SNMPv2
> > > >    notification protocol operations.  The parameters used
> > > to generate a
> > > >    notification are called 'notification parameters.' 
> > The format of
> > > >    parameters used for SNMPv1 notification protocol operations is
> > > >    refered to in this document as 'SNMPv1 notification
> > > parameters.'  The
> > > >    format of parameters used for SNMPv2 notification
> > > protocol operations
> > > >    is refered to in this document as 'SNMPv2 notification
> > > parameters.'
> > >
> > > What about SNMPv3 'notification parameters'??
> > > I guess, this is similar to my comment earlier in section 1.4.
> >
> >
> > Since 'notification parameters' are determined by the version
> > of protocol
> > operations, there are only SNMPv1 and SNMPv2 'notification
> > parameters.'
> > I don't think there's anything we need to change here.

See "4.1.3.  Notification Originator" below.

> >
> >
> > > > 4.1.1.  Command Generator
> > > >
> > > >    A command generator must select an appropriate message
> > > version when
> > > >    sending requests to another entity.  One way to achieve
> > > this is to
> > > >    consult a local database to select the appropriate
> > > message version.
> > > >
> > > >    In addition, a command generator MUST 'downgrade'
> > > GetBulk requests to
> > > >    GetNext requests when selecting SNMPv1 as the message
> > > version for an
> > > >    outgoing request.  This is done by simply changing the
> > > operation type
> > > >    to GetNext, ignoring any non-repeaters and
> > > max-repetitions values,
> > > >    and setting error-status and error-index to zero.
> > >
> > > Correct me if I am wrong, but this does not provide the same
> > > functionality
> > > from the command generators point of view. Should that be noted??
> >
> >
> > This is true, but I think we would be adding too much detail about 
> how
> > to implement code if we said anything more here.

Understand.

> >
> >
> > > > 4.1.3.  Notification Originator
> > > >
> > > >    A notification originator must be able to translate
> > > between SNMPv1
> > > >    notification parameters and SNMPv2 notification
> > > parameters in order
> > > >    to send a notification using a particular SNMP message
> > > version.  If a
> > > >    notification is generated using SNMPv1 notification
> > > parameters, and
> > > >    configuration information specifies that notifications
> > > be sent using
> > > >    SNMPv2c or SNMPv3, the notification parameters must be
> > > translated to
> > > >    SNMPv2 notification parameters.
> > >
> > > here I see the first time that SNMPv2c and SNMPv3 are treated
> > > more equal
> > > and then maps upon SNMPV2 notification parameters.
> >
> >
> > Well, this is the first place it talks about the actual SNMP message
> > version being used for sending notifications.  I don't think there's
> > anything to change here.

Now I see why SNMPv3 is not always mentioned/repeated again after 
SNMPv2.
The difference is an SNMP message and SNMP PDU simply said. SNMPv3 uses
SNMPv2 PDUs. Altough, that is quit clear to me, but I did not get this
fully while reading the document.
An 'ignorant' reader would be confused by this.

Therefore, I believe it could be a good idea to add a line in section
1.3 explaining that SNMPv3 is not always mentioned/repeated specifically
when it is about/uses the same definitions as SNMPv2.

> 1.3.  SNMPv3
>    SNMPv3 also uses the SNMPv2 definitions of RFCs 1905 through 1907 
> and
>    the SMIv2 definitions of 2578 through 2580 described above.
I suggest adding something like:
Therefore, thoughout this document when SNMPv3 is not mentioned 
specifically
the same definitions of SNMPv2 apply for SNMPv3.


Hope this helps,

Harrie
------------------------------------------------------------------
Author of MOD-SNMP, enabling SNMP management of Apache HTTP server