[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: iSCSI Discovery and SendTargets

    Mark and NDT team,
    Nice write-up of your discussions.  In summary I would like to strongly
    support the position of option 1 in your memo, which is keeping SendTargets
    as-is with the few minor modifications to support aggregation tags, but not
    much else.  We do need to contain the scope of SendTargets, but removing it
    from the spec would be a tremendous loss of a very simply yet powerful
    feature.  My supporting comments are as follows:
    1. Keeping SendTargets basically as-is, but with the addition of aggregation
    tags is a very small increment over what must already be implemented for
    general iSCSI login, authentication and text processing.  It is basically
    just another text command that has very wide spread utility.  
    2. The fact that a discovery session, where SendTargets can be performed,
    uses the exact same authentication and login mechanisms is a fundamental
    benefit of the scheme.  Alternatives will require their own (albeit similar)
    implementations for authentication.  Deploying, configuring and maintaining
    AAA infrastructure has always been a stumbling block for customers and
    complicating this with additional protocols and clients will not help
    3. The complication of an iterator can be avoided if we restrict the usage
    of SendTargets to a session on a well-known target or clearly document the
    potential issues of blocking a connection in an implementation.  However, I
    would support the definition of an iterator if there is consensus.  This is
    not a show-stopper.
    4. Splitting SendTargets into multiple commands (ReportTargets and
    ReportPortalGroups) seems unnecessary and not relevant.  I have not heard
    the entire discussion surrounding ReportPortalGroups, but it would seem that
    this information would be better reported via the MIB or at least should be
    made available via the MIB.  Even if there is a need for such a command then
    it appears to be an entirely separate issue.
    5. Enhancing SendTarget responses to include additional information
    regarding certificates or boot related information appears to be in the
    category of 'creeping elegance' and does not to need to be considered at
    this time.  Facilities will be in place to establish the session needed to
    perform SendTargets anyway, and returning additional information that allows
    one to avoid using these facilities is purely an optimization.
    6. An example of SendTarget's power and simplicity (as-is) is the ability to
    use it to create a SendTargets tree as you've described.  There is really
    nothing that "needs" to be changed from the current scheme to support this
    behavior.  This is a perfect example of how the very same mechanism can be
    used to 'scale' in environments from very small plug-and-play workgroups to
    a large centrally administered, highly secured, enterprises.
    So, from an expediency and philosophical perspective I believe we should
    implement SendTargets now and contain the number of proposed changes to keep
    it as simply as possible.  We should NOT move this to another document,
    since it is really just another text command, but a very powerful one at
    + Paul Congdon             + Email: +
    + Hewlett Packard Company  + Mail Stop:  5662           +
    + HP ProCurve Networking   + Phone:  (916) 785-5753     +
    + 8000 Foothills Blvd      + Fax:    (916) 785-5949     +
    + Roseville, CA   95747    + Mobile: (916) 765-4056     +


Last updated: Tue Sep 04 01:04:33 2001
6315 messages in chronological order