|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Huntington Beach DRAFT minutes
Comments/objections to the list. To save him the time,
Doug Otis's standing objection to the including of
Fixed Interval Markers in the iSCSI spec is hereby noted.
I do hope nobody else is interested in reopening that issue.
Thanks, --David
IETF IP Storage Interim Meeting
Huntington Beach, California
February 6, 2002
-------------------------------
-- Boot draft. (John Hufferd)
No new issues, will check on changes in main draft. -05 version will be
prepared
for Minneapolis.
-- Stringprep
No new issues. Still waiting/needing underlying docs from idn WG; draft
available
IESG has asked about importance. David Black has said "very important".
-- SLP/iSCSI (Dave Peterson)
No new issues. David Black announces that Security folks have looked at
2-IP address
config issue, and have recommended not doing anything here, as it's an IPsec
problem, and ipsec folks are showing some interest in solving this one.
Until
a solution is available, dynamic configuration of IP Storage systems that
use
two IP addresses for tunnel mode IPsec may be difficult.
-- iSNS (Josh Tseng)
Security config is stored per-interface, not per-target to avoid IPsec
issues.
Monitoring and notification ports have been separated.
Security - iSNS can be used to register security settings. This enables
devices to
determine what security parameters are available/desired.
iSCSI implementer can decide what to use.
Q: Has security hole been opened by storing/configuring security info in
iSNS?
A: Mandates IPsec be used to discover security policies, security
parameters/policies
used to talk to the iSNS need to be manually configured.
Q&A: How is this sort of problem solved in general for IP networks?
Generally
by some sort of vendor-specific config tool so that this
information is
known in advance.
Discussion of iSNS support of pre-shared key. Currently supports key per
interface.
Will remove pre-shared key support from iSNS as pre-shared key
per-interface
isn't the right granularity - will leave this to existing IPsec
mechanisms.
iSNS and FC-iSCSI mapping - iSNS can store this mapping, and in -08 iSNS
draft
will have ability to store an FC-usable WWN per iSCSI device.
If iSCSI
node name is in EUI form (WWN), the WWN (eui64) will get set
automatically
from this. iSNS can produce hashed WWN in local assignment
space for
convenience. This is all about the FC World Wide Node Name, not
Port Name.
Also handle setup of this in reverse direction. (Note: device
can provide
a EUI64 name itself, if it so desires)
Persistent hashing needs to be supported.
Bob Snively: EUI64 is not in and of itself a valid WWN for Fibre Channel.
There
is a mapping definition between EUI64 and WWN - should be in
FC-FS Annex K
and/or chapter 14. Make sure that names that go into iSNS (and
can be
retrieved) are WWNs that are ok for FC.
Example in Josh's slides requires gateway to operate as an FC
E_port.
Q: Is iSNS needed? A: Produces consistent mappings across multiple
gateways,
no serious advantage for a single gateway.
-- iSNS MIB (Josh Tseng)
No serious changes from -00 to -01. Keith has concerns about (1) how the
word
"instance" is used in documenting the MIB (terminology problem only) and (2)
support for values that change on next initialization, which excludes
on-the-fly
changes without re-initialization. Keith and Josh will resolve this for -02
version offline.
-- iSCSI MIB (Marj Kreuger)
iSCSI/SCSI MIB relationship has been worked out - changes to iSCSI MIB to
fit cleanly
with SCSI MIB. Authorization model published - will be going into a
separate MIB.
Latest version of draft has proposal for writable attributes/objects.
Authors,
WG chairs and MIB doctor are in process of deciding what to do with this
MIB, as
it's likely to be useful to WGs other than IPS.
Need to cross-check authorization model with iSNS for consistency.
See ftp://ftpeng.cisco.com/mbakke/ips for SCSI and iSCSI MIB object models.
No objections to object and object model changes to iSCSI MIB.
Need to go look at other MIBs that do this sort of authorization - IPsec and
SNMP configuration MIB.
Paul Koning - use name in certificate rather than certificate itself (i.e.,
hash
of it) as principal for authorization so that info survives
certificate
expiration.
Keith - separate this MIB from the iSCSI MIB and ask Bert Wijnen (O&M AD)
about wider applicability. We then have the option to do it as
either an IPS MIB (iSCSI or IPS-generic) or a more-generic MIB.
Consensus - Authorization MIB approved as an IPS WG work item - authors, WG
chairs, and MIB doctor will figure out how to take it forward.
-00
draft to be submitted by Minneapolis -00 cutoff deadline.
Writable attribute work is in progress - please send comments on what should
be writable to authors and the list, ditto anything that appears
to be
missing. All writable attributes will have minimum access of
read-only
(so no write support is REQUIRED).
Q: Will security attributes overlap with iSNS? Should those parameters be
moved
to iSCSI MIB?
A: No
Future work -- Session Profile
-- iSCSI Naming and Discovery (John Hufferd)
- 6-byte vs. 8-byte ISID issue
Trying to provide support to keep implementations (use this word instead of
vendors)
from having complicated dependence on each other to generate
unique ISIDs.
Keith's issues - need to make sure that this is about different
implementations,
not vendors. Big problem is use of OUI scopes this to vendors
as opposed
to implementations.
4 byte "vendor id" is also problematic, as MAC address won't fit.
Issue - proceeding in this direction could cause use of multiple MAC
addresses
per IP interface to get multiple ISIDs.
Big concern appears to be dependence of ISIDs on hardware resulting in
naming
being tied to hardware. (ISIDs need to be dynamic, ISID could be
reassigned
to a replacement device for example). Opponents to 8 byte ISID
fear 8 bytes
would "encourage" poor design.
On other side, implementers are looking to reuse unique (MAC)
identification
information rather than have to re-generate it, e.g. to simplify
mfg process.
A simplification, but not tying ISID to hw, since configurable.
Keith suggests - MUST be configurable to allow support for hot-swap and the
like.
Marj - that's already in the document.
Topic taken offline, and compromise proposal brought in on Thursday evening:
ISID compromise - leave field size at 6 bytes, use first two bits as a type
field
with one value reserved for future use. Result in that a 6-byte
IEEE-
controlled identifier assigned by the manufacturer (e.g.,
MAC) can be
used (2 MSBs in a MAC are not part of its uniqueness). The
intended
use is "factory assigned default". MUST be configurable,
MUST persist
across hot swap, isn't the right approach to scaling this
up.
See Section 9.1.1 and 9.1.2 of the main iSCSI draft for warnings on not
tying this
to hardware (i.e., putting the Ethernet MAC in here is not a
good idea).
No objections to proceeding with this solution.
** Chairs to check that RFC editor will not change bit and byte numbering,
also
whether the ADs will have issues with the ordering conventions
used in
the main IPS documents, particularly iSCSI. **
- Long-lived Discovery sessions
NDT proposes not to allow long lived discovery sessions (adding async
messages,
and NOPs for dead session detection). Other ways exist to solve
problem.
Put wording into draft indicating that discovery sessions are intended to be
short
lived, and it's acceptable for a target to tear down long-lived
sessions
if it's short on resources.
- Stringprep
Discussion of IETF process for stringprep - Work is being handled in the idn
WG.
Handles internationalization of strings. Some characters which
appear
the same are represented in different ways in UNICODE.
Stringprep is an
algorithm which produces the same canonical form for all
representations.
IPS stringprep draft exists in order to get the grunt work done
in time
for us to use it. For English, this converts everything to
lower case,
but there are more complex canonicalization procedures for
characters
used in other languages.
- SLP status update
SLP/IPsec will go into RFC2608bis; moving from proposed to draft
standard.
Notification support in RFC 3082
SLP MIB under construction (individual submission -- which
group?)
- Portal Group Tags (Dave Peterson, John Hufferd's slides)
Target portal group tags mark portals that can participate in a
multi-connection
session. Appears in MIB, Send Targets and SLP. Initiator
analog appears
only in MIB.
Target Portal Group Tag and ISID - These are the endpoints of the SCSI
Nexus, and
parallel nexii are NOT allowed.
Problem here is Transparent Gateways, where more than one gateway wants to
present
the same iSCSI node (e.g., to a Fibre Channel Fabric). If two
gateways
both present a portal group tag of 1 to iSCSI, result is
parallel Nexii.
Marj - thinks transparent gateways are not possible/reasonable. Will break
persistent reservations. Need coordinate target portal groups
across
gateways.
Dave P - Thinks that 90%+ transparency is possible, and in particular for
persistent reservations.
Q: If gateway is transparent, why does this matter?
A: Parallel nexii result from simple example on Dave P's slide.
Josh - iSNS can handle this coordination.
Dave P - iSNS is one possibility, this is a proposal for another.
Examples on Dave Peterson's slides do not do any coordination across
gateways.
- Gateway coordination would lead to proprietary solutions, but
it's
the default if nothing is changed.
- Have target allocate the target portal group tags to the
gateways -
not workable for reasons on Dave P's slides
Proposal is to use 8 bytes for target portal group tags and add
OUI-qualified
format for target portal groups.
Comment - Gateway naming format could provide an alternate approach to this
problem.
Favors a non-transparent approach where gateway presents
different iSCSI
node names.
Comment - Fibre Channel doesn't have a solution to this problem. LU serial
number
(VPD page 83h) or something like a volume header is used to
solve this.
Comment - Keep in mind that this proposal is to provide a means for the
gateways
to distinguish themselves. If gateways merge into a shared
identity, all
sorts of things break in the absence of shared state across the
devices.
More discussion occurred, on Thursday, the following conclusion was returned
to the group:
Target Portal Group Tag issue (from Dave Peterson's piece of the
presentation
yesterday). These tags are used in Send Targets. If two
gateways
independently report Send Targets for the same node name with
different
portal group tags, one could wind up with a change to
configuration
of the node when the second gateway is discovered; that would be
bad.
Gateways should use different node names - higher level software
can
cope with LUs presented via both node names. If two gateways
claim
the same iSCSI node name, they must perform the duties of an
iSCSI
node - ISID, TSID, and Target Portal group coordination. Can
generate
independent iSCSI node names with EUI/WWN embedded via IQN
format.
General principle is that the responsibilities of an iSCSI node for
coordinating
ISID, TSID, and portal group tags applies independent of whether the iSCSI
node
is an initiator (e.g., multiple ports/HBAs), target (e.g., multi-ported disk
array) or gateways (multiple gateways exporting same/shared LUs).
-- Grant EUI64 Draft (Robert Grant, McData)
2 gateways, like Dave Peterson's scenario - want to have the same name for
all
the ways in which one iSCSI device is presented to Fibre
Channel. This
is about the Fibre Channel side of naming, vs. previous issue
that was
about iSCSI side of naming.
This gets more complicated when one considers gateway failures.
If the gateway does the naming, the same iSCSI initiator may have more
than one FC WWN and hence the FC config loses the value of the
single iSCSI node name. Gateway coordination and making sure
the name doesn't change (e.g., for zoning, lun masking mapping)
are complex. This gets really ugly as the number of gateways
(e.g., for bandwidth addition) goes up.
Proposed solution - have iSCSI supply a node-level EUI64 (yields FC WWN)
to the gateway. Support in iSNS (being done) and provide an
operational
login key to communicate the EUI64 in the absence of iSNS.
iSNS does solve the problem. Discussion of what happens when trying to
scale
up iSNS does not seem productive.
Operational key is useful when eui-based naming is not used but one wants to
work through a FC gateway. Support would be optional.
Alternate proposal - Have eui64 names assigned to any device that wants to
do
this, preferably by the vendor.
NOTE: This is about an eui64 name at the node level, not the port level.
This is anticipating a more powerful role for FC Node WWN in Fibre Channel
configuration.
No consensus to add this to current iSCSI draft - continue to work this as
an independent draft for later consideration. May want to
produce
a larger draft on bridge/gateway issues in general.
-- iSCSI Framing
Long, interesting discussion ... FIM = Fixed Interval Markers
Initial proposal to move FIM to an experimental draft if specified as MAY on
transmit
accepted. Later, after sentiment in the room taken, decision unanimously
reversed --
No matter if FIM MAY or SHOULD on transmit, will remain in the iSCSI draft.
Due to concerns among many that moving it to an experimental draft would
effectively
kill FIM.
Room about evenly split as to whether FIM is critical to achieving 10 Gbps
speeds.
Room about evenly split (vote 19-18 for FIM to be SHOULD) on whether FIM
should be
SHOULD or MAY on transmit. FIM bidirectionally negotiated.
After approximately a 2 hour discussion, could get no clear consensus.
Chairs made decision that due to this lack of consensus, FIM on transmit
will go to MAY.
FIM on receive will stay MAY. Chairs invited the proponents of FIM to write
up an
informational draft and submit to WG on the advantages/benefits of FIM.
Also indicated to the group that the status of FIM may change at some later
date,
depending on implementation results.
Also -- TCP ULP framing will not be discussed in the main iSCSI draft.
-- iSCSI Open Mike
** Need to make sure that unrecognized values for recognized keys are
ignored when
a list with values that are recognized. ** A key with a single
unrecognized
value results in a reject.
Discussion of spec clarity - Suggestion that there should be no implied
requirements in the spec, so that a PICS can be written by
scanning for the
the capitalized words. Everyone should read the spec looking
for potentially
implied/misleading text. For example, see "reissued w/same
CmdSN" sentence
in Chapter 2 that does not have an RFC 2119 word.
Upper case MAY NOT is not defined in RFC 2119, there are several instances
of this
in Appendix E (Send Targets) that need to be removed.
Discussion of some aspects of error recovery - what needs to be done after
connection
failover. This is all covered in Chapter 7.
Dave Peterson will look into iSCSI error recovery issues for tape and
similar
devices (don't reissue commands w/o knowledge of tape position,
issue
can also affect optical jukeboxes and the like) and draft an
implementer's
note indicating the minimum level of recovery support needed for
current
tape devices - Mallikarjun to help.
----- Thursday, February 7, 2002 ------
-- Agenda Bashing
Add iSCSI carryover slot for ISID and Target Portal Group tag items up
front.
(This discussion included in Monday's notes, for continuity of issues)
-- Last Call and RFC Procedures (Elizabeth Rodriguez)
Discussion of WG Last Call, steps involved in an I-D becoming an RFC,
including
things that authors need to check and/or be aware of to avoid delays in the
process.
-- SCSI MIB (Yaron Lederman)
IETF IPS SCSI MIB design team has developed a new SCSI (not iSCSI) MIB with
significant participation from T10's SCSI experts.
See Yaron's slides. Virtualization, Bridging and SCSI Command sets are out
of scope. SCSI MIB exports information for SCSI entities
visible over
a SCSI nexus.
Object model is posted on Mark Bakke's site at Cisco - URL has been sent to
the list and is in the agenda.
MIB has a notion of "Authorized Initiator" at Target to allow controls over
Initiators that cannot attach. Structural analog on Initiator
side
is "Discovered Target."
Note that the statistics are optional to implement - the structure is being
provided to present the statistics if they are maintained.
Discussion that some systems keep a recent history, but not a complete
history
of statistics. Julian suggests that amount of statistics to be
kept
be expressed in terms of size of data rather than time it
covers.
Request for a fixed-size error log (last N). There is already an event log
MIB that would be appropriate for keeping the last N errors.
Need to
check how to index this from another MIB. This is an open issue
for
further consideration on the list, but tape discussion doesn't
seem
to be a motivating example - this is characterized as a need for
a SCSI TAPE MIB as opposed to a SCSI MIB.
MIB will NOT model SCSI mode pages.
Discussion of versions of SNMP - SMIv2 is being used, and everything
works with SNMPv1, v2c, and v3, except for two uses of counter64
to record statistics that can not be accessed by SNMPv1. SNMP
security
policy is orthogonal to MIB specification and conformance
statements
(requirements to implement) - one may be required to implement
something that is made inaccessible by the security policy.
** SCSI MIB design team will recheck current use of counter64. Network
Management Area of IETF is now discouraging use of counter32 to
provide SNMPv1 access to counter64 elements in order to
encourage
people to move to at least SNMPv2c. ** SUBSEQUENT UPDATE: This
use of counter32 is still considered acceptable.
Keith: usual guideline is that if a 32 bit wrap is possible within an hour,
then counter64 should be used for the element.
MIB Family - discussion of coordination across SCSI and iSCSI MIBs. FCP
MIB
example on family slide is completely hypothetical to illustrate
intended
structure. iSCSI and SCSI ports are separate concepts, each for
its
own MIB.
Still a work in progress - please look at the MIB and MIB structure and
comment on the list.
-- IPS Security (Bernard Aboba)
This is about changes to the -07 version of the security draft to close open
issues - authors believe that all open technical issues have closure that
should
be acceptable to the WG. See Bernard's slides.
- IKE fragmentation
Long certs, or multiple certs can cause IKE UDP packets to undergo IP
fragmentation,
and lots of actual network devices don't deal with fragments.
Text will contain warnings about things that cause large IKE packets, and
advice
to use network equipment that supports IP fragmentation.
- Dangling SAs
Will delete paragraphs prohibiting "Dangling SAs".
- Identification Payloads
Add a MUST for ID_FQDN. FCIP and iFCP want to have a SHOULD NOT for
ID_USER_FQDN,
iSCSI will have a MAY.
Further discussion of the ID's to which "SHOULD NOT" was applied should go
to the list.
- SLPv2 Security
RFC 2608bis will retain RFC 2608 security model in order to get to draft
standard.
Separate draft will be written on IPsec for SLPv2 in fairly short order.
Once
that gets done, a bunch of the IPS Security text on IPsec for SLPv2 will get
removed. SLPv2 authorization text will be in SLPv2 drafts.
- iSNS Security Policy
Had to change per-target security to per-IP Interface, otherwise IPsec
Security
Policy Database breaks (can only have one per IP interface). Lots more
stuff
on the slide, Mark Bakke to provide equivalent text for SLPv2.
IPsec for iSNS is MUST implement when iSNS is used with iFCP.
- IPS Authorization
Will describe identification mechanisms, authorization mechanisms, and
limitations
(IPsec best for intra-domain use due to cert limitations and
issues with
multiple trusted cert roots).
This supports the separation and generalization of the Authorization MIB
from the
iSCSI MIB.
iSNS is also an authorization mechanism for at least iFCP, and could be used
for iSCSI (if iSCSI chose to delegate authorization to iSNS -
would
require IPsec for iSNS).
- Rekey Calculations
Removed "safety factor" from rekey calculations and deleted AES-CBC material
because we are only using AES-CTR. Still wind up needing to rekey prior
to sequence rollover.
- Transforms
Summary of currently specified transforms.
David Black to sent prod-o-gram to Ted and Barbara (esp.
Barbara) on drafts.
Q: What about AES-CBC?
A: AES-CTR draft currently appears to be making sufficient progress - this
is the path to high performance.
NOTE: XCBC is the MAC extension mechanism, not the combined mode (combined
mode
has Intellectual Property Rights issues, the MAC extension does
not).
- SRP Issues
Will add a 3072-bit group to the appendix if we can find one. Current text
key
value size limits can hold a 3072 bit value.
- Transport mode vs. Tunnel Mode
MUST support ESP, tunnel mode, and replay detection.
If the IPsec implementation is a host according to RFC 2401, then MUST
support
transport mode.
Q: Does this mean that FCIP (and iFCP) would need to support both
tunnel and
transport mode?
A: No, only devices acting as a host, as defined in RFC 2401.
Add an "if" pointing to the ipsra ipsec-dhcp RFC as the way to do DHCP
through
an IPsec tunnel (avoid using a MUST).
Concern expressed that notion of an embedded security gateway is not
consistent
with RFC 2401.
David Black to work with Bernard on clearer text explaining RFC 2401
requirements,
and to check issue of "embedded security gateway" being
consistent
with RFC 2401.
Add some text describing current possibilities for gateway discovery.
David Black to send Paul Hoffman a prod-o-gram to get ipsra requirements doc
out
so that ipsec-dhcp draft makes it out of RFC Editor Queue.
2 Consensus calls
- Everything except tunnel/transport - no objections
- Tunnel/transport requirements - clear majority of room, rough consensus.
Noted: Most are not familiar with RFC 2401, as of the time of this
consensus call.
-- Open Mike
Charter update is still in the works - Allison says its because IP Storage
is a
good WG and hence doesn't have "on fire" requirements for her attention.
Change "SHOULD" to "MUST" for use of serial number arithmetic for CmdSNs.
----- Friday, February 8, 2002 -----
-- FC Management MIB (Keith McCloghrie)
This will replace both the FC Management MIB (transferred from the ipfc WG)
and the FC Fabric Element MIB (RFC 2837). Major revision and rearchitecture
to fit IETF guidelines and partition by functionality.
Major changes from ipfc FC Mgmt MIB
- Remove objects not specific to FC -- entity MIB WG will define
MIB support for sensors, trap registration is
handled by basic
SNMPv3 MIBs, events - RFCs 2819 and 30114, inventory
- RFCs 2737
and 2790, revision number [wrong approach], a few
other objects,
plus obsolete stuff.
- Now linked to ifTable in interfaces MIB (RFC 2863), removed
objects
already covered in the interfaces MIB, and explained
how ifTable
objects apply to Fibre Channel.
- Removed scalars due to AgentX MIB (RFC 2741). Need to
partition MIB
among agents (e.g., multiple vendors) at instance
level, hence
global scalars cause problems for AgentX.
- Counters: Counter64 for traffic counters, Counter32 for error
counters
(traffic counters could wrap a 32 bit integer in
less than one
hour).
Issue: What about counter64 vs. SNMPv1 - would like to avoid losing access
to the traffic counters when running SNMPv1. Additional
counter32
objects would add overhead. Requests from multiple WG members
to
provide this access.
** Keith and DLB will check with Ops & Mgt ADs on current position on this -
IETF is about to make SNMPv1 historic **. SUBSEQUENT UPDATE:
This use of counter32 to allow SNMPv1 access is ok.
- "Connectivity Unit" renamed to "FC Management Instance",
defined as
"a separable managed instance of Fibre Channel
functionality"
Change: Put in reference to FC-MI as strong input to defining set of things
that
are interesting to manage with this MIB.
Open Issues
- Name Server.
- Class F counters.
- Zoning information.
Ralph Weber mentions new HBA management server being defined in T11 - sounds
like
this ought to be a separate MIB. Suggests drawing T11's
attention to
Section 13 (comparison to ipfc Mgmt MIB), where changes are
described,
Ralph will send email.
Keep Section 13 around and deal with its reference to the ipfc version of
the
FC management MIB at WG Last Call - there will probably be a
stable T11
version of the old FC management MIB that can be referenced at
that time.
Put in Class F counters now. Defer the Zone Server. Add Security Server to
the list of deferred Servers, ditto Alias and HBA Servers. Also
a QoS
server under development in T11.
FC name server should be a separate MIB. Should be first on the list of
servers
for which MIBs are to be generated after this one is stable.
Section 14 contains a comparison to RFC 2837, no functionality will be lost,
but stuff does move to other MIBs.
Class 4 to be put in after Minneapolis. Can put in traffic counters for it
after Minneapolis.
Murali to be responsible for informing WG of appropriate points to undertake
MIB definition work for items that we deferred here.
RFC 2837 and old FC Mgmt MIB have allocated portions of MIB object space
(experimental 94 in latter case). These will never go away -
they're
either that MIB or "Not Implemented".
Need to deal with FCIP MIB dependence on old FC Mgmt MIB, and iSNS MIB
dependence on RFC 2837 - those should import from this new MIB.
FCIP MIB is in the process of being updated.
** Josh and Keith to check iFCP MIB to see if it has any similar dependence
issues. **
-- FCIP MIB (Anil Rijhsinghani)
Currently at -01. Matches current FCIP model, some changes for NAT.
Now deals with FCIP device that can have multiple FCIP Entities - will look
at adopting "FC Management Instance" terminology from previous MIB. RFC
2837
references will be updated to previous MIB. TCP-specific counters removed.
Keith: IPv6 MIB work has added per-interface IP counters, and might
be appropriate place for per-interface TCP counters. Contact
Juergen
Schoenwalder to pursue this.
Structure - FCIP Entity, Link and Connection tables. Dynamic and Static
Route
tables for FC reachability. Static route table allows
pre-configuration
of connectivity. DLB requests that care be taken to make it
clear that
the latter two are about FC Fabric routing and reachability.
Work to be done: Align with latest FC-BB-2 changes/requests, add support for
security (will look at authorization MIB coming out of iSCSI),
and SLP,
write conformance statements.
FCIP folks need to look at use of IKE info for Authorization - if they want
to
do this, then use of Authorization MIB coming out of the iSCSI
work may
be appropriate.
Will need to define notifications. Keith - be careful not to get carried
away -
these are for exceptional conditions, and really want to
generate only
one notification in most cases.
Discussion of possibly treating endpoint of an FCIP link as an interface -
might
be related to issues in IPsec space about treating endpoint of
an IPsec
tunnel as an interface for routing purposes.
SLP additions - Dave Peterson is not aware of anything that's needed here.
-02 version expected for Minneapolis.
-- iFCP MIB status (Josh Tseng, no slides)
iFCP will not need Authorization MIB emerging from iSCSI - will use iSNS for
Authorization, so Authorization info might be extracted from
iSNS MIB
to use a common authorization MIB.
No known open issues.
-- iFCP (Charles Monia)
Revision 9 is believed to be done (ready for WG Last Call) except for some
pending security stuff.
Revised terminology to better explain address translation vs. transparent
modes.
Added TCP port number to N_PORT info. Stale frame detection is
now mandatory,
added FC-4 link services, and replaced broadcast service to use
TCP (UDP
approach could have caused IP fragmentation in some
circumstances).
Added support for "liveness test" message to make sure TCP connection is
still up.
Tracking security changes - will update to most recent changes.
Have same issue with AES-CTR and AES-CBC-MAC w/XCBC references
making
progress in a timely fashion as in the main IPS security draft,
will
deal with them in same fashion as main IPS security draft.
-- FC Encapsulation (Ralph Weber)
Vi Chau has asked to be removed from list of Authors. Adding all the rest
of
the EOF codes for Class 4. iFCP does not need Class 4 EOF codes.
-- FCIP (Ralph Weber)
At -08, needs Class 4 EOF codes. Editorial changes still being made.
-- iSNS for iFCP (Josh Tseng, no slides)
Is in good shape, no issues.
-- SLP for FCIP (Dave Peterson, no slides)
Waiting for some more clarity on security. Will consult with Mark Bakke
(see
yesterday's IPS Security draft session) to get the SLP security
discussion/
modifications into this draft.
-- Open Mike
Last call procedure - authors tell WG chairs on list or directly that draft
is
ready for WG Last Call, chairs announce WG Last Call and define
Last Call
period.
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA 01748
+1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500
black_david@emc.com Cell: +1 (978) 394-7754
---------------------------------------------------
Home Last updated: Fri Mar 01 23:18:24 2002 8978 messages in chronological order |