Subject: RE: [Isms] ISMS charter broken- onus should be on WG to fix it

From: "Nelson, David" <[email-masked]>
Date: Tue, 13 Sep 2005 11:46:54 -0400

Juergen Quittek writes...

> It [call home] looks like a good topic for a BoF session in the 
> OaM area.
> There we could find out the relevance of the problem and discuss
> requirements for potential solutions.  Also there we can identify
> which working group would be the right one to deal with the issue.
> 
> But until then, I propose that we let the ISMS group work on solving
> its original problem.

I agree that specifying Call Home functionality in SNMP should be out of
scope for ISMS, which is attempting to solve a different, well-defined
problem.

I also agree with Dave Harrington's suggestion that the SSH transport
mechanism for ISMS should be designed such that the initiation and
termination of SSH sessions, and the use of such sessions by the command
generator and command responder, would not preclude another WG from
specifying Call Home functionality using the ISMS work, unless that
requirement overly complicated the ISMS design work.  I would call this
division of labor an appropriate "separation of concerns". 

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: Keith McCloghrie <[email-masked]>
Date: Tue, 13 Sep 2005 10:00:06 -0700 (PDT)

Dave,

I support the "alternative" you are recommending.

Thanks,
Keith.

> As primary editor of the SSH draft (SSHSM), I spoke with Eliot last
> week. I agree that it is difficult for him to develop a reasonable
> proposal that piggybacks on the SSH draft, because the SSH draft is so
> incomplete.
> 
> I am not convinced that SNMP needs to add a new call-home (CH)
> functionality, nor that this feature is needed in SNMP now, but there
> is a danger that CH might never be possible if we don't consider its
> impact on the SSHSM model before SSHSM is cast in stone. If it
> complicates the SSHSM model, I would prefer to not include it; a new
> model could be developed to replace or supplement the SSHSM model if
> demand increases for this functionality.
> 
> I recommended to Eliot that he contribute some text for the SSH
> document, describing the CH functionality and proposed elements of
> procedure, that I could include as an appendix to the SSHSM document
> so the WG could review his proposal, and then the WG could decide
> whether it should remain as an appendix, be incorporated into the SSH
> document, be split out as a separate document, or be abandoned
> altogether. I felt this was a reasonable alternative to making the
> decision whether CH is or is not in scope at this time. He has not yet
> had a chance to develop the text and send it to me. 
> 
> David Harrington
> [email-masked]
> 
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Eliot Lear
> > Sent: Monday, September 12, 2005 3:53 PM
> > To: Sam Hartman
> > Cc: IETF Discussion; [email-masked]; [email-masked]
> > Subject: [Isms] ISMS charter broken- onus should be on WG to fix it
> > 
> > Sam,
> > 
> > I believe the approach you have proposed is quite simply wrong.  As
> an
> > AD you're supposed to provide technical oversight and not 
> > simply hold a
> > popularity contest.  If you have technical questions or wish to
> > challenge me on a technical point, I think that's fair game.
> > 
> > As I've written, the path we are headed down technically will not
> work
> > in the face of firewalls and NATs, and nobody has refuted this.
> > 
> > Furthermore you've heard from a reasonably large customer (Boeing)
> as
> > well as your predecessor on the prevalence of such middle boxes that
> > demonstrates the complexity of today's environment and the 
> > need for this
> > sort of functionality as part of the solution.
> > 
> > You've heard from an author of SNMP that the major 
> > architectural change
> > is the use of session based security and NOT CH, the same from the
> > former O&M AD and IETF chair.  You've heard from a service provider
> as
> > well as numerous members of the community who see the problem.
> > 
> > You may or may not have yet heard from other standards bodies 
> > but if you
> > were to delay it is quite possible they will chime in since one was
> > specifically interested in this sort of function.
> > 
> > The amount of changes required to support CH cannot fully be 
> > ascertained
> > until more of the the [Todo]s are filled in with Dave's draft, but I
> > don't imagine the work would be much more than:
> > 
> >  - specifying how to initiate the connection and if necessary turn
> it
> >  - the identity used for requests received from command 
> > generators that
> >    did not initiate the connection along with potential
> prepopulating
> >    of various tables
> >  - an appendix of how the SNMP-TARGET-MIB would be populated
> >  - a discussion on when to initiate connections and what to do when
> >    they fail (mind you this is needed anyway regardless of CH)
> >  - security considerations involving firewalls, blocking, etc.
> >  - possibly one additional table describing the state of SSH peer
> >    connectivity (which probably wouldn't be bad to have anyway).
> > 
> > Decide for yourself if you think this is a substantial amount of
> text,
> > but I won't leave it to your imagination for long.  I will 
> > attempt this
> > week to post a derivative of the draft that Dave is working on to
> give
> > people an idea of what the changes would be.
> > 
> > Again it's difficult to diff an incomplete specification.
> > 
> > Eliot
> > 
> > >>>>>>>>>>> "Eliot" == Eliot Lear <[email-masked]> writes:
> > > 
> > > 
> > >     Eliot> I request an extension of the deadline for comments to
> > >     Eliot> September 21st on the following basis:
> > > 
> > >     Eliot>  - the period of comment has been less than a week, far
> > >     Eliot> shorter than the normal period of IETF-wide review.  -
> of
> > >     Eliot> the time allotted, the principle instigator of 
> > this review
> > >     Eliot> has been absent from debate for five days due to prior
> > >     Eliot> commitments.  That was me.
> > > 
> > > Hi, Eliot.  I have not made any determination as yet about whether
> I
> > > will pull ISMS from the Thursday telechat and am unlikely to make
> a
> > > final determination until the time of that telechat.
> > > 
> > > 
> > > When I originally ruled call home out of scope I gave you some
> > > suggestions for how to approach things from a process 
> > standpoint.  In
> > > evaluating your request I will consider how much progress has been
> > > made on these issues so far and on whether it is likely 
> > that you could
> > > make additional progress on these issues by September 21.
> > > 
> > > Let us go back and consider my original advice to you:
> > > 
> > >   When the charter is sent to me for IESG review, ask me to 
> > send it out
> > >   for external review (IETF wide) rather than just 
> > approving it; I will
> > >   honor such a request.  You will need a proposal ready to 
> > present to
> > >   the community when the charter comes out for review.  The
> proposal
> > >   should include proposed modifications to the charter to 
> > make call home
> > >   in scope.  In addition you probably want to answer the following
> > >   concerns:
> > > 
> > >   * People believe that architectural changes to SNMP 
> > should happen in
> > >     the management not security area.  Either convince them 
> > that this is
> > >     OK in the security area, propose moving the working group, or
> > >     propose splitting the work appropriately.
> > > 
> > >   * Address the concerns about the lack of MIBs and other 
> > facilities for
> > >     managing call home.  Have a proposal ready for what is 
> > involved in
> > >     doing the work.
> > > 
> > > 
> > >   * Understand concerns Bert is likely to raise and respond to
> them.
> > > 
> > > 
> > > 
> > > so, here are some specific questions related to our progress to
> date
> > > on these items.  Answering these questions will help me determine
> > > whether extending the review period to September 21 is likely to
> be
> > > productive.
> > > 
> > > 1) Have you proposed a specific set of charter changes?  Who has
> > >    supported these charter changes?
> > > 
> > > 2) How have you addressed the specific concerns about the 
> > location of
> > >    the work ?  Who has agreed with your proposed resolution?
> > > 
> > > 3) Is there a consensus emerging that CH needs to be solved 
> > as part of
> > >     ISMS?  This is the part where additional time is most likely
> to
> > >     help you, but I think it fair to ask who has supported
> blocking
> > >     ISMS on CH so far.  Note that people who support CH but who
> > >     believe it could be done in a separate working group or who
> have
> > >     not expressed an opinion do not count.  They may well count
> for
> > >     justifying support for a CH BOF or for justification of a
> > >     publication request for an individual submission adding 
> > CH to the
> > >     SNMP architecture.
> > > 
> > > 
> > > 4) What response have you given to concerns about whether the
> > >    architectural extensions for CH are sufficiently well 
> > defined?  Who
> > >    has supported this proposal?
> > > 
> > > 
> > > 
> > > 5) How are your discussions going with Bert to resolve his
> concerns?
> > >     What about other key members of the management 
> > community who have
> > >     expressed concerns?
> > > 
> > > 
> > > 
> > > Here's how I'm going to make a decision.  I believe that in order
> to
> > > get a change to the SNMP charter it is necessary to make
> significant
> > > progress on all of these issues.  I'm going to evaluate your
> answers
> > > and consider whether I think the progress to date makes it 
> > likely that
> > > you will have sufficient support for a new charter by September 21
> > > without significant opposition.  In other words whether the 
> > community
> > > and IESG can agree to the new charter by the end of the 
> > review period.
> > > If the progress to date makes it likely that we're headed in that
> > > direction, I'll grant the request.  Otherwise I will ask the IESG
> to
> > > approve the charter on Thursday.
> > > 
> > > 
> > > There's an internal issue that may well prevent the charter 
> > from being
> > > announced before the 21st even if no formal extension is granted.
> > > 
> > > 
> > > --Sam
> > > 
> > 
> > 
> >