Subject: [Ips] New iscsi-slp draft

From: Mark Bakke <[email-masked]>
Date: Thu, 15 Apr 2004 13:09:15 -0500

I've just submitted a new iscsi-slp draft, to address comments made on 
the list
during the last few months.  The draft is available at:

ftp://ftpeng.cisco.com/mbakke/ips/iscsi/draft-ietf-ips-iscsi-slp-07.txt

Issues Resolved:

1. Security Comments

   Make sure that IPsec is required whenever SLP is used
   to distribute security policy, including any of the auth-
   fields.

2. Update the Security Considerations and Security Implementation
   sections as per emails

3. Update document to deal with NATs and template chaining

4. Update template for iSNS discovery

Emails used to update from -06:

12/17/03 - David Black - FCIP and ISCSI SLP drafts

  IESG Issue 1 - Add language requiring IPsec whenever
  security policy (auth-xxxx and boot-list attributes)
  are distributed via SLP.

  IESG Issue 2 - Fix up security mechanism language, as provided
  in 12/23/03 email.

12/23/03 - David Black - FCIP and ISCSI SLP draft revisions

  Updated references to the IPS-SEC draft.

  Updated Security Considerations section.

1/16/04 - David Black - draft-ietf-ips-fcip-slp-08.txt

  Ted Hardie's NAT and template chaining comments.

1/23/04 - David Black - iSCSI SLP draft

  Updates to security considerations.

1/28/04 - Bill Studenmond - Finding iSNS using SLP

  Need to provide TCP/UDP transport information when discovering
  an iSNS URL.

  Need to discover server priority for iSNS URLs if possible.

1/29/04 - Josh Tseng - (in response to Bill's email)

  Proposed solution for TCP/UDP transport

  Non-SLP solution for server priority

3/22/04 - David Black - iSCSI SLP draft status

  iSNS text additions.

4/14/04 - David Black - iSCSI SLP draft

  Gentle reminder :-)

Changes (by section):

Finding Targets Based on Initiator Credentials

  Added text:

    Also note that the auth-xxxx attributes are
    considered to be security policy information.  If these attributes
    are distributed, IPsec MUST be implemented as specified
    in the Security Implementation section below.

Discovering Storage Management Services using SLP

  Changed URL paragraph to:

    A storage management server's URL contains the domain name or IP address
    and TCP or UDP port number.  No other information is required.

NAT and NAPT Considerations

  Added text to first paragraph (same as FCIP draft):

    Also note that SLP advertisements that occur inside a
    private address realm may be unreachable outside that realm.

  Added reference to RFC1900, as in FCIP draft.

  Updated second bullet to:

    Configure the NAPT device to provide default mapping(s) for the
    well-known port(s) and use the default IANA-assigned iSCSI TCP port
    number in service URLs, when possible.

  Deleted third bullet (SLPv2 proxy).

The iSCSI Target Concrete Service Type Template

  Added to auth-name, auth-addr, auth-cred, and boot-list attributes:

    # This attribute contains security policy information.  If this
    # attribute is distributed via an Attribute Reply message,
    # IPsec MUST be used.

iSCSI Storage Management Service Templates

  Added transports attribute (tcp and udp supported, default is tcp)

    transports = string M L
    tcp
    # This is a list of transport protocols that the registered
    # entity supports.
    tcp, udp

Security Considerations

  Updated section

Security Implementation

  Updated section

References

  Removed reference to RFC3082 (not referenced in text)

  Added reference to RFC1900 (non-normative)

  Updated iSCSI, N&D, Security, and Stringprep references to use
  the RFC numbers.

  Updated Author name format in references to match what the RFC
  editor will require.

Misc

  Updated copyright dates

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

---

From: William Studenmund <[email-masked]>
Date: Fri, 16 Apr 2004 17:49:53 -0700

> during the last few months.  The draft is available at:

[snip]

>  Non-SLP solution for server priority

I'm sorry I didn't get to you yesterday about this.

I've been thinking about it, and I'm not sure I like this idea. Just 
for everyone
else, the idea is that we only have the active iSNS server advertising
itself via SLP. In the case of failover, the backup server advertises 
itself
and we wait for the original SLP advertisement to expire.

I think the thing I dislike most about this is that the other location 
methods,
DHCP and heartbeat, report all the servers. Not including a server 
priority
means SLP acts differently.

Additionally, it means that iSNS servers have to put lifetimes on their 
SLP
registrations. And the registrations have to have a lifetime that does 
not
severely impact failover (if the idea is that only active hosts are 
advertised).

Since the iSNS clients have to worry about failover anyway, I think 
it'd be
better to include the priority. Then SLP discovery would work the same 
as
heartbeat and DHCP.

Take care,

Bill

---

From: Josh Tseng <[email-masked]>
Date: Fri, 16 Apr 2004 20:53:58 -0700 (PDT)

I agree with Bill.  Although I lost the original
e-mail thread, I believe the comment was to include a
priority field in the SMS template, and not to rely
exclusively on the iSNS server heartbeat for failover
priority.

Josh

--- William Studenmund <[email-masked]>

> ATTACHMENT part 2 application/pgp-signature
x-mac-type=70674453; name=PGP.sig

		
__________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online by April 15th
http://taxes.yahoo.com/filing.html

---

From: Mark Bakke <[email-masked]>
Date: Mon, 19 Apr 2004 09:05:38 -0500

Makes sense; I had seen the original email, then saw a (I think) later one
that said we didn't need it.

What should I call the field?  How about:

   server-priority = integer
   # The priority a client should give this server, when choosing
   # between multiple servers with the same protocol type.
   # When multiple servers are discovered for a given protocol type,
   # the client should (must?) use the server with the highest (lowest?)
   # server-priority value.

Is the above description adequate?  Do we want "should" or "must"
in the last sentence?  Should it be "highest" or "lowest"?

Let me know,

Mark

Josh Tseng wrote:

>>>I've just submitted a new iscsi-slp draft, to
>>>      
>>>
>>address comments made on 
>>    
>>
>>>the list
>>>during the last few months.  The draft is
>>>      
>>>
>>available at:
>>
>>[snip]
>>
>>    
>>
>>> Need to provide TCP/UDP transport information
>>>      
>>>
>>when discovering
>>    
>>
>>> an iSNS URL.
>>>
>>> Need to discover server priority for iSNS URLs if
>>>      
>>>
>>possible.
>>    
>>
>>>1/29/04 - Josh Tseng - (in response to Bill's
>>>      
>>>
>>email)
>>    
>>

---

From: William Studenmund <[email-masked]>
Date: Mon, 19 Apr 2004 09:31:58 -0700

> in the last sentence?  Should it be "highest" or "lowest"?

How about:

# The priority a client should give this server, when choosing
# between multiple servers with the same protocol type.
# When multiple servers are discovered for a given protocol type,
# this parameter indicates their relative precedence. Server
# precedence is protocol-specific; for some protocols, the primary
# server may have the highest server-priority value, while for
# others it may have the lowest. For example, with iSNS, the primary
# server has the lowest value (value 0).

I'm trying to get at: 1) different protocols may have different server
priority values already, and this field should map to that. 2) Exactly
what a client does with multiple servers is protocol-specific (we
should leave it alone in this spec). 3) We need to say somewhere
what iSNS does. As this document serves as the SLP definition for
iSNS, I figured this is the best place to mention it.

I expect that any sms protocol other than iSNS will have a separate,
follow-on document that indicates what its protocol is, its transports,
and how to use this field.

Take care,

Bill

---

From: Mark Bakke <[email-masked]>
Date: Mon, 19 Apr 2004 11:44:25 -0500

OK; I like that better.  I'll send an 08 (with this plus David's 
implement vs used
changes) later today.

--
Mark

---

From: Mark Bakke <[email-masked]>
Date: Fri, 30 Apr 2004 13:40:37 -0500

I've just submitted iscsi-slp-08 with the changes; it is available at:

ftp://ftpeng.cisco.com/mbakke/ips/iscsi/draft-ietf-ips-iscsi-slp-08.txt

--
Mark

---

From: William Studenmund <[email-masked]>
Date: Fri, 30 Apr 2004 12:03:07 -0700

> ftp://ftpeng.cisco.com/mbakke/ips/iscsi/draft-ietf-ips-iscsi-slp-08.txt

I quickly scanned it, looking at the changes regarding sms support.

Looks good, though I was a bit confused by one bit:

    transports = string M L
    tcp

Is the first 'tcp' a typo?

Take care,

Bill

---

From: Mark Bakke <[email-masked]>
Date: Fri, 30 Apr 2004 14:16:08 -0500

Bill-

It's not a typo; the line right after the definition is the default to use
if nothing is returned.  The line after the description is the set of
possible literal values.

--
Mark

---

From: William Studenmund <[email-masked]>
Date: Fri, 30 Apr 2004 12:57:14 -0700

> if nothing is returned.  The line after the description is the set of

Ok!

Take care,

Bill