Re: coex draft last call

Sorry for the last-minute nature of this report, but I've now
had a chance to work through the latest coex draft, and identify
a number of points where I found the text unclear.

   Most of what follows are effectively requests for clarification.
In most cases I can probably work out what I *think* is intended
from other comments in the document, but such detective-work
seems unhelpful, and a potential source of problems.   I'd suggest
that it's worth saying the same thing in two places, rather than
risk an implementor going astray because they've omitted to make
a connection between two comments at opposite ends of the document!


  I also noted a number of stylistic points - such as inconsistencies
in phrasing and/or layout (e.g. compare 4.1.2.3 with 4.1.2.4), or
areas where the description felt a little unclear, but I've tried to
concentrate on more substantive issues here.  Particularly where
the required behaviour seemed uncertain (or unexpected).

I trust these comments are of some use.

Dave
-------------------------------------------------------

	p10:  2.1.1   bullet (10).
The final sentance is somewhat misleading.
Surely it's the combination of the effects of bullets (10) *and* (11)
that provides the SMIv1->SMIv2 transparency for SNMPv1 agents?


	p17:  3.2     bullet (2)   second section.
Why is the original source of the notification to be extracted
*only* from the variable bindings?  If the proxy is receiving
the notification from the notification originator via SNMPv2c
or SNMPv3, then this notification would not naturally include
an snmpTrapAddress varbind, but the proxy would (potentially)
know the originating IP address from the incoming PDU transport
information.   Could it not use this information when forwarding
the SNMPv1 notification?

   Though there is a potential problem in the case of a "proxy
chain" - where the proxy forwards it to a second proxy, also using
SNMPv2c or SNMPv3.  This second proxy would need to recognise that
the transport address that it saw was *not* that of the original
notification originator.


	p18:  3.2    bullet (6)
This description says to strip out snmpTrapAddress.0, but says
nothing about the other two varbind that may potentially have
been added - snmpTrapCommunity.0 and snmpTrapEnterprise.0.

  In particular, the snmpTrapEnterprise.0 varbind has already
been used to set the SNMPv1 enterprise notification parameter
(see 3.2 bullet(1) ).   Retaining it here would seem unnecessary,
so it would be sensible to remove this as well.

  How to handle snmpTrapCommunity.0 seems less obvious - in
particular, should the outgoing SNMPv1 notification use this
community name, or that determined from the proxy's own configuration
(e.g. the SNMP-COMMUNITY-MIB)?

  Should the snmpTrapCommunity.0 varbind be retained or not?  Does
it make a difference whether this value is the same as the SNMPv1
community notification parameter on the outgoing notification?


	p20:  4.1.2  last paragraph
This talks in general terms about "some combination of SNMPv1 and
SNMPv2 access to MIB data".  But in practise, everything that
follows is talking specifically about SNMPv2 access to MIB data,
in response to an SNMPv1 request.   There is nothing about the
other possible combinations.

 Presumably, "homogeneous" access is not regarded as a problem
(i.e. SNMPv1 access to MIB data in response to an SNMPv1 request,
or SNMPv2 access to MIB data in response to an SNMPv2c or SNMPv3
request)?  In such a situation, the multi-lingual nature of the
agent is effectively irrelevant - yes?

  What about SNMPv1 access to MIB data in response to an SNMPv2c
or SNMPv3 request?  If such an approach should not be used (and
I can see no good reason to do so), then perhaps this should
be stated explicitly.

  I believe it would be easier to follow if the introduction to
section 4.1.2 stated up front, that the rest of the section
referred purely to SNMPv2 access to MIB data in response to
an SNMPv1 request.


	p24:  4.1.2.4   second list, bullet (1) 
Presumably an endOfMibView exception counts as an "error" in this
situation (or at least triggers the bullet (2) processing)?
This is not entirely clear, but would seem the obvious behaviour.


	p27:  4.2.1    bullet (3)
The processing of a 'tooBig' response to a GetBulkRequest feels
surprising.   In particular, it's inconsistent with the processing
of a 'toobig' response to the equivalent GetNextRequest.  Why should
we try so hard to provide a ("sub-minimal") answer to a GetBulk?
If this behaviour is intentional, it would merit a word of explanation.


	p28:  4.2.2    bullet (3)
The processing of Counter64 results in a proxy environment is
inconsistent with the of processing Counter64 results in a
multi-lingual environment (section 4.1.2.4, second bullet (1) )
In particular, a proxy should retry the whole request, not just
the Counter64 varbinds.
  Is this difference intentional?  If so, then it may be worth
pointing it out explicitly.


	p28:  4.2.2    Deployment Hint
I'm not convinced that the not-in-view suggestion here is sensible,
unless the proxy uses different principals for forwarding SNMPv1
requests and SNMPv2/v3c requests.   If a proxy uses a single principal
for communicating with a particular agent, then any Counter64 type
objects *should* be in-view for incoming SNMPv2c or SNMPv3 requests.
Adding the suggested access restriction would affect such requests,
as well as forwarded SNMPv1 requests.
  If this suggestion is retained, then it should make mention of
this problem.


	p33:  5.2.1   CBSM returned parameters
Where is the value for 'securityName' obtained from?  Is it the
value of 'snmpCommunitySecurityName' in the selected row of the
snmpCommunityTable?   If so, then it's worth stating this.

Similarly, where is the value for 'maxSizeResponseScopedPDU' found?
snmpTargetAddrMMS ?

It would also be worth mentioning any requirements on the
securityStateReference at this point, rather than waiting until
section 5.2.2.


	p35:  5.2.4
If the proxy is forwarding from one example of a community-based
Message Processing Model to another (e.g. v1->v2c or vice versa)
where do the securityName, contextEngineID and contextName values
come from?  Are these the values returned by the processing
described in section 5.2.1?   If so, is it worth stating this
in 5.2.4?


	p36:  5.3   third/fourth paragraphs
The third paragraph states that the snmpTargetAddrTMask is only
to be used where explicitly stated - presumably when matching on
incoming transport addresses, rather than identifying individual
destination addresses.
  In a situation where the snmpTargetAddrTMask is *not* to be used,
how should transport address matching be done?  In particular, if
the snmpTargetAddrTMask is a non-zero length string (i.e. this is
a "wildcard" row), should a check be done on the (exact) value of
snmpTargetAddrTAddress anyway, or should the whole row be skipped?


   One final issue:
Is it worth saying something about AgentX in all this?  The AgentX
protocol operations are essentially SNMPv2 in a different guise,
so an AgentX master agent could be viewed as a sort of proxy.
Is it worthing saying something along these lines?
   Or is it really too late to consider this properly?

-------------------------------------------------------------

Dave