Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLPv2)
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
> 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' **)
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' **)
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".