RE: Evaluation: draft-ietf-snmpv3-coex-v2 - Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Man agement Framework to BCP

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Russ, I will still go along with the RFC-Editor note if that clears
your discuss. However.... checking in yet more detail (while trying
to writeup the explicit RFC-Editor instructions), then I think
what you want me to state is:

OLD:
   -      The snmpCommunityTable allows creation and deletion of
          community strings, which is potentially a serious security
          hole.  Access to this table should be greatly restricted,
          preferably by only allowing write access using SNMPv3 VACM and
          USM, with authentication and privacy.
NEW:
   -      The snmpCommunityTable allows creation and deletion of
          community strings, which is potentially a serious security
          hole.  Access to this table should be greatly restricted,
          preferably by only allowing write access using SNMPv3 VACM and
          USM, with authentication and privacy (also known as
          confidentiality).

However... if you look at section 8 in more detail, you will see that
2nd para also talks about "privacy". Also the one but last para in that
section talks about "privacy".
Now, those 2 paragraphs are from the MIB security boilerplate/guidelines
that we composed (in co-operation with Steve and Jeff and some IAB
security folk as well) earlier this year (January). We have passed
quite a few documents with that text by now, even some at full STD now.

So... do you really want to stick to the requested change, and if so, 
would more text need to be changed, and would my guidelines/boilerplate
need to be changed as well?


Thanks,
Bert 

> -----Original Message-----
> From: Russ Housley [mailto:housley@vigilsec.com]
> Sent: woensdag 11 juni 2003 14:11
> To: Wijnen, Bert (Bert); Wijnen, Bert (Bert); Internet Engineering
> Steering Group
> Subject: RE: Evaluation: draft-ietf-snmpv3-coex-v2 - 
> Coexistence between
> Version 1, Version 2, and Version 3 of the Internet-standard 
> Network Man
> agement Framework to BCP
> 
> 
> Bert:
> 
> > > > > >                     Yes    No-Objection  Discuss *  Abstain
> > > > > >Russ Housley        [   ]     [   ]       [ X ]      [   ]
> > > > >
> > > > >    Since this document will obsolete RFC 2576, it 
> would be very 
> > helpful if
> > > > > the document contained a summary of the changes which are 
> > implemented by
> > > > > this document.  I assume that Appendix B is not 
> intended to be 
> > included in
> > > > > the final RFC.  I think that the change summary 
> should be at a much 
> > higher
> > > > > level than Appendix B.
> > > > >
> > > >Mmmm... when we still had Scott on the IESG, he always 
> wanted it in
> > > >the appendix material as far as I remember. Anyway, it 
> weas in appendix
> > > >B when we had rfc2576, which obsoleted 1908, so we 
> are/were just following
> > > >what was already in an earlier RFC. I do know that in 
> quite a few RFCs,
> > > >such a list of updates occurs in an appendix.
> > >
> > > I do not really care about placement.  I did not think 
> that Appendix B was
> > > really to be included in the final RFC because it also 
> included other 
> > history.
> > >
> >That other history is also the diffs/changes between earlier 
> RFCs... not
> >diffs/changes at the I-D level. So the intention is to keep 
> it all in the
> >RFC-to-be.
> 
> Okay.  I withdraw this comment.
> 
> > > > >    In section 8, the document says: "... USM, with 
> authentication and
> > > > > privacy."  Please change "privacy" to "confidentiality."
> > > > >
> > > >Well, we have Authentication and Privcacy protocols in 
> USM. That is how
> > > >they have been known since oh mid 90s or so.
> > > >
> > > >So we have a authNoPriv and a authPriv way of communicating.
> > > >So I think that sticking to privacy is better given the 
> history and
> > > >the name of the fields and bits that we use.
> > >
> > > How about ".. USM, with authentication and privacy (also known as
> > > confidentiality)."
> > >
> >That seem quite acceptable to me. Can we do so with an 
> RFC-Editor note?
> 
> Fine.  I will send a note to the secretariat to clear the DISCUSS.
> 
> Russ
>