Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLPv2)
RFC 4018

Note: This ballot was opened for revision 09 and is now closed.

(Allison Mankin) Yes

(Harald Alvestrand) No Objection

(Steven Bellovin) (was Discuss) No Objection

(Margaret Cullen) No Objection

(Bill Fenner) No Objection

(Scott Hollenbeck) No Objection

(Russ Housley) No Objection

(David Kessens) No Objection

(Thomas Narten) (was Discuss) No Objection

Comment (2004-08-09)
No email
send info
>             Finding iSCSI Targets and Name Servers Using SLP

title doesn't satisfy id nits

>    Each of the iSCSI targets in the drawing can appear at two addresses,
>    since two network interfaces are present.  Each target, would have
>    two service URLs.

not necessarily. there could be one URL with a DNS name, where the DNS
name maps to two addresses.

>    This functionality is well within the scope of the current SLP
>    protocol.  However, it does have two consequences for implementors:
> 
>    - A service-agent responding to requests for iSCSI targets MUST
>      implement SLP over TCP; UDP only is not enough.  This is not
>      an issue, since TCP is a requirement for iSCSI implementations
>      that use SLP for other reasons.

Question: It seems as if the intention is that TCP be used for
unicast. That probably makes sense, given the example in which the
unicast path may be over the internet in general. But saying "use
unicast' is not the same as saying "use TCP". It would be good to make
clear if using TCP (as opposed to unicast UDP) is really what is
intended in this document.

>    Attributes that include non-ASCII characters will be encoded using
>    UTF-8, as discussed in [RFC3722] and [RFC3491].

sounds like a normative, not informative, reference.

>     hostnumber  = ipv4-number

has syntax for IPv4, but not IPv6. Is this OK?

> 4.1.2.  Supporting Access by Multiple Identities to the Same Target
> 
>    If a target is to allow access to multiple host identities, more than
>    one combination of auth-xxxx attributes will need to be present.
>    Since service URLs must be unique, each of these must be registered
>    under its own service URL.

I don't understand the first part of the last sentence. Is this right?

same comments on NAT as per draft-ietf-ips-fcip-slp-09.txt. That is:

Section on NAT seems superficial and is probably incomplete. Have the
recommendations actually been tested and are they complete? Also, will
the corresponding iSCSI protocols even work through a NAT device?  If
not, how about changing:

> Below  are  some
>    recommendations for dealing with SLPv2 and NAT/NAPT devices:

to something like:

   Below are some recommendations that may make it possible to use
   SLPv2 in the presence of NAT/NAPT devices. Note that these
   recommendations may not be sufficient in all environments.

Alternatively, remove the section entirely? The question of getting
SLP to work in the presence of NATs is probably worthy of its own
document and is a general SLP issue.

(Jon Peterson) No Objection

(Bert Wijnen) No Objection

Comment (2004-05-13 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
draft-ietf-ips-fcip-slp-09.txt has text that is "right justified"

(Alex Zinin) No Objection

(Ted Hardie) (was Discuss) Abstain

Comment (2004-05-11 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
This document references the snmp: URI scheme, and it needs a reference
to the appropriate document (draft-black-snmp-uri-04.txt).  It could probably
be informative, since the snmp:  uri is only in the examples, but since
it is not yet a registered scheme, some reference seems to be required.

They have updated the section on NAT handling and NAPTs, and since they have added
text that this probably won't work through a NAT/NAPT, I've shifted from DISCUSS to
ABSTAIN.  But I note that this document still has some broken assumptions.  They've
added this text:

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

Apparently in response to my original question:

>I don't think I understand how the first one helps (is there some default
>mapping through NAPTs presumed for well known ports?) 

pointing to this text in the original:

- Use the default IANA-assigned FCIP TCP port number in service URLs,
     when possible.

The problem remains that unless the party outside the NAPT knows what the
mapping will be and to use it instead of the port assigned, it won't work.  
I was asking if they thought there was some default mapping between the 
well known port and the port that a NAPT would select--trying to get them to 
see that there isn't such a thing and that this was broken.  They've chosen to say 
"use a default mapping", but any such mapping would be local convention and knowable
only by some out of band mechanism.   You would have to say "turn off port translation for this port".