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 > dbharrington@xxxxxxxxxxx > > > > -----Original Message----- > > From: isms-bounces@xxxxxxxxxxxxxx > > [mailto:isms-bounces@xxxxxxxxxxxxxx] On Behalf Of Eliot Lear > > Sent: Monday, September 12, 2005 3:53 PM > > To: Sam Hartman > > Cc: IETF Discussion; iesg@xxxxxxxx; isms@xxxxxxxx > > 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 <lear@xxxxxxxxx> 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 > > > > > > > > > > > _______________________________________________ > > Isms mailing list > > Isms@xxxxxxxxxxxxxx > > https://www1.ietf.org/mailman/listinfo/isms > > > > > > _______________________________________________ > Isms mailing list > Isms@xxxxxxxxxxxxxx > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf