The area director for this working group, Harald Alvestrand,
discussed where we are - we have a set of specifications,
some implementations and some faith that the specifications
and implemenations will give us security.  He also discussed
where we can go - the market is asking us to stop tinkering
and start shipping.  The working group can either ask that
the documents with identified revisions be promoted or abandon
hope and close the working group.  

The introductory document, draft-ietf-snmpv3-intro-02.txt, has
had no comments since the posting of the last ID.  There were
no major comments on it and no objections to forwarding it for
publication as informational when the core specifications are
forwarde.

The coexistence document, draft-ietf-snmpv3-coex-02.txt, has
been tidied up for consistency with the other documents and the
SMIv2 documents.  The major point of discussion was how to handle
counter64s in proxies.  In most v1 situations they are treated as
simply not in view.  In the unlikely case of proxying from a v1
manager to a v2/v3 target they currently cause a no such name error.
In the given proxy case (v1 manager, v2/v3 target) both options have
problems.  Skipping over counter64s may require large amounts of
packet exchanges if they are clustered together and it may cause
problems with the relative timing for multiple objects in one messasge.
The current scheme will cause managers doing walks to terminate early.
One possible solution is to use a different error, such as GenErr.
This would still cause the walk to terminate but the manager wouldn't
think it had reached the end of the mib.  Some other larger but
straightforward changes were suggested but not described, they should
be posted to the mailing list.

It was agreed that, while it would be good to do so, this document did
not have to move forward with the rest of the core set of documents.
Comments for this document should be submitted by Jan 15 1999 and the
counter64 question should be resolved on the mailing list.

An implementation report from Wes Hardaker was provided.  They have
been working on a full implementation - MD5, SHA, and DES but not
proxy.  There are still a few known bugs outstanding and some more
interoperability testing is needed.  This was a non-author implementation
and several clarifications were requested on the mailing list and
in the meeting.  The meeting clarifications are in a separate section
later in the minutes.  This is a freely available reference implementation
and can be found at http://ucd-snmp.ucdavis.edu/snmpv3.html.

Doug Maughan and some others from the IPSEC community were asked to
analyze the core specifications.  Their analysis may be found in
draft-maughan-nsa-snmpv3-sec-00.txt, it suggests a different modularity
and placement of interfaces (the ASIs) but does not affect the external
behaviour.  An implementation of their architecture will be attempted in
1999.  Doug came by to discuss their analysis.

One point of the discussion was if implementors would follow the
ASIs directly or not.  The ASIs are used for clarity and modularity
and are not a required part of an implementation.  Doug and his
co-authors feel that many implementors might follow the ASIs anyway
and that the security may be increased by reducing the information
accessible by all modules.  Some of the implementations that have
been described on the mailing list do follow the ASIs and some,
including many SDK vendors, don't.  An open question with respect
to the newly suggested modularity is how it would work with multiple
access control modules.

Two other points were made but not debated.  The first was that the new
modularity would line up better with what might happen in a sub agent
scheme and the second was that to actually take advantage of such modularity
the message format would need to be redone.  

Lastly Doug was asked, as a security type, about reports.  He sided
with those that feel reports might be a problem and therefore should
be deferred.

Another implementation report was provided by Lauren Heintz.
This was also a non-author implementation and was done several
months ago with the documents being updated to include their comments.
They implemented MD5, SHA and DES and didn't use the ASIs.  Overall
they found the documents acceptable with some areas of confusion.
The areas included - some mib descriptions especially the row status
and when rows can be modified, row status and storage type, what security
level to use for certain reports and an example in the description of
pass phrases to keys being incorrect.

The chair also made some general requests.  One was to re-set the
subject line when changing the subject of a mail message.  The
other was for information about publicly available test sites to
be posted to the mailing list.

Joe Marzot is on the team working on the implementation that
Wes Hardaker described earlier.  Joe discussed the areas they
felt needed clarification in more detail.  The working group
then discussed the areas and tried to reach consensensus.

In RFC2272 there are contradictory statemetns regarding whether a
report should be sent when the reportable flag is zero.  While 
several people thought it would be good to allow a manager to disable
reports by setting the reportable flag to zero this was counter to
the previous consensus of the working group in Munich.  The consensus
was to finish the changes from Munich, of which this one was missed,
and that in cases where the reportable flag was inconsistent with the
PDU type then the PDU type should override the reportable flag.

In RFC2272 and RFC2275 the security parameters for reports are not clearly
defined.  The suggested fix is to not send reports with invalidly cached
data.  Bert (the editor) will examine the edits.

The documents do not clearly describe the Denial of Service (DOS) potential
inherent with reports.  There was some discussion about how many other
items we might need to document that would lead to DOS attacks and which
docuemnts should include any such clarifications.  There was vague consensus
to make a small number of changes to mention the DOS possibilities but that
they should not paint reports as evil as the same possibilities exist
with any unauthenticated response.

Two points were mentioned by Joe but not discussed by the group.
In RFC2274 3.3.2, the elements of procedure indicate the caching
of data which may later be found to be in error.  The data include
user name, security engine ID and security level.
In RFC2274 3.1.1.a states that the security state reference is used
in preference to formal parameters, so a zero length engine id from
a probe request would cause problems.

In RFC2274 sections 3.2.3.a and 3.2.3.b discuss how to handle unkown
engine ids.  If (a) is chosen the engine id is added, in an
implementation specific way, to the LCD if (b) is chosen an
unknown engine id error is returned.  The document doesn't give much
guidance in choosing between these two options.  There was a vague
consensus to add some hints for implementations to choose, but that
it was an implementation question.  One example was that an API might
allow information to be passed into the engine to allow it to determine
if it should do discovery or not.

In RFC2272 the description of msgid could be clearer regarding whether
separate message ids are used for retried requests.  The consensus was
to modify the text to use the word "SHOULD" instead of "should".  There
is no protocol reason that would require a "MUST" but a user should
use a new id.

Randy Presuhn then discussed report generation in RFC2272 and
it's follow on draft-ietf-snmpv3-mpc-02.txt.

In section 7.1.3.c of the RFC was unclear which security information
to use, a clarfication has been added to the draft.  This clarification
will be kept.

What should be done in section 7.2.5.d, the case where, on an
incoming message, the auth flag is not set and the priv flag is set?
There was some discussion about the fact that this message can only
be generated by a broken implementation and that sending a report is
unlikely to help clear up the problem.  A general principle is of only
sending reports for differences in configuration and not for broken
implementations is suggested without a check on consensus.  There is a
consensus to change the RFC and draft to simply discard the above message.

Randy proposes to add a reference to section 7.1.3 in section 7.2.6.a 
for fields not extracted if the decrpytion step failed.  There should
be no changes from the RFC or draft.

In the draft the generation of a report was added for the case of
an ASN.1 parse error when the reportable flag was set.  This was
a chagne from the RFC and was added to simplify expeimentation with
new PDU or data types.  The consensus was to return to the handling
specified in the RFC.  One suggestion is that when the community
starts defining new methods, pdus or data types it should also define
a mib to specify what the agent supports.

The RFC was unlcear on how to handle a response or internal PDU
with the reportable flag set.  A clarification to process the PDU
as though the reportable flag was not set was added to the draft.

A summary of the proposed changes is:
1) Never generate a report in response to something whcih has
   been IDed as belonging to the unconfirmend class.
2) Reports may only be generated as a result of processIncomingMsg()
   returning an error OID/value from the security service.
This item was removed as per previous discussion
R1) Never generate a report in response to soemthing in which
    the reportableflag is zero.

Russ then proposed that after the fixes for inconsistency and clarity
are incorporated in the IDS they be moved forward to the IESG for
publication as draft RFCs.  Note that the documents must move forward
as a group.  Additional interoperability information will also be submitted.  
There was major support and no objections for this proposal.


The following schedule was agreed to:
        Dec 18         revised text due for current IDs
        Jan 15         revised IDs posted to snmpv3 list
        Jan 15         interoperability report due
        Jan 15         revised text due for coexistence doc
        Jan 18 - Feb 1 working group last call
        Feb 3          IDs forwarded to IESG
        Feb 8-22       IETF Last Call


The topic of allowing a user to be in multiple groups was raised.
The chair ruled that it had been decided and, for these docs,
rejected on the mailing list.  1) it would be a change in design
which is not currently allowed except for show stoppers.
2) that the architecture would allow it to be added later.

One member of the WG felt that a "fast one" was being pulled,
that the group was an operational problem, that schedules are too
aggressive and the group was not actually looking for comments.
He suggested we may need new leadership to conclude this.  To "pull
people together, to get operational experience".  In response 
Harald, as AD, (harald.alvestrand@maxware.no) suggested that if
people don't feel comfortable with the apparent group consenssus the
issue should be raised to him.  If people can convince him that
there are specific problems the docs won't advance, unspecific comments
will be discarded.  Any specific problems should be either made public
on the mailing list or privately to Harald.

Lastly there was a brief discussion about the dates and if there would
be enough time to review the docs or if the dates could be pused back any.
The critical date is Feb 25, which is the last meeting of the IESG before
the next IETF meeting.