[drinks] AD review of draft-ietf-drinks-spp-framework and draft-ietf-drinks-spp-protocol-over-soap

[Richard Barnes <[e-mail]>]

I have reviewed these documents in preparation for IETF LC.  Overall, I
think they hang together OK, even if the use of XML and SOAP does make me
feel like I'm back in the 90s :)

I've requested LC, but there are a few comments below that I would like you
to consider along with other LC comments.

Overall, these specifications would read better if they were not separated
as they are, especially since there doesn't seem to be any demand for
non-SOAP transports.  But they are intelligible separately, so I won't
object to processing them as-is.

--Richard


===== draft-ietf-drinks-spp-framework-09 =====

** TODO: See RFC 5486 for use cases

Section 1, "for data distribution to SSP" - Expand "SSP"

Section 1, "SED is typically used" - Expand "SED"

Section 2 - It would be helpful to define "Session Establishment Data", at
least by reference.

Section 4 - Do we realistically expect there to be other transports for
this protocol?  If not, let's delete this section or move it to an appendix.

Section 4.11, "provided in SPP Protocol over SOAP document" - Needs a
normative reference.

Section 5.1 - This section needs to define the semantis for the cDate/mDate
elements, as is done in Section 6.1 et al.  (I assume these are "created"
and "modified", respectively.)

Section 5.2 - It seems odd that these identifiers have defined contents,
but not a data structure.  Shouldn't these be moved from the SOAP document
to this section?

Section 5.3 - It seems like the "conforming specification MUST define"
incantation could be moved to the top.

Section 6.2, "When a Public Identifier is not member of any Destination
Group, it is intended to be associated with SED through the SED Records
that are directly associated with the Public Identifier."
Since the "dgName" illustration above shows the association to a
Destination Group, it would be helpful to note that these direct
associations are provided using "sedRecRef" elements in individual
identifiers.

Section 6.2 - In a related vein, why is "sedRecRef" not defined at the
level of PubIdType, along with "dgName"?  As is, it's only defined for
TNs.  This seems to imply that other identifier types must be part of a
Destination Group.  Why is that?

Section 6.2 - It seems like more needs to be said about NumberValType,
especially as it is used for TN / RN / TNP.  For TN/RN, MUST it be the full
E.164 number?  For TNP, is it a truncated E.164 number?

Section 6.2 - "Whether the Registry can accommodate the open number plan
semantics is a matter of policy and is beyond the scope of this document."
No, it's not!  The semantics of TNR need to be clear regardless of the
number plan.  Whether a given registry *accepts* TNR objects for open
number plans is up to the registry.  The semantics are not clear to me.
Could you provide an example of how TNR works in an an open-plan
environment?


===== draft-ietf-drinks-spp-protocol-over-soap-07 =====

I did not review the WSDL or examples in detail.

Section 5, "Clients and Servers MUST use HTTP Digest Authentication" - Is
there a reason that TLS-layer authentication (client certificates) is not
acceptable?  Or other, stronger techniques that might come out of HTTPAUTH.

Section 7.1 - It seems like this section should move to -spp-framework.

Section 7.2 - Given that you're using namespaces, prepending "sppp" to all
the element names here seems wasteful.  Instead of "<urn:spppAddRequest>",
just use xmlns:sppp="..." and "<sppp:addRequest>".

Section 7.2 - It would save some schema/writing if you pulled out a few
common attributes of the request and response objects (clientTransId,
minorVer; clientTransId, serverTransId, overallResult, detailResult).
These would also be good candidates for things to put in the SOAP header.
Even if you don't restructure this, you could remove the repeated
definition of "ResultCodeType".

Section 7.2.1.2, "clientTransId: Zero or one client transaction ID.  This
value is simply an echo of the client transaction ID" - It would be clearer
to be make this a MUST.

Section 7.2.5 - Given that you have these nice batch request/responses, why
would you bother defining the individual request/response types?  Instead
of "<spppAddRequest>", you would just have
"<spppBatchRequest><addObj></spppBatchRequest>"  Given all the SOAP
overhead, you can afford the extra characters, and it will save a lot of
spec/code.  This change is even backward-compatible with servers that
implement batch requests.

Section 11 - It would be nice to refer here to the authentication and
authorization concerns discussed in Section 5 and Section 6.