The SPIRITS (Services in PSTN requesting Internet Services) Protocol
draft-ietf-spirits-protocol-08

[Ballot comment]
This is much improved, it seems.

From John Loughney, Gen-ART:
It seems that they addressed some, not all the points raised.  I wouldn't
put a discuss on the draft, though. These things could be handled via
the RFC Editor.

NITS:

1) Formatting still off, but that is a minor point.
2) Status of this Memo should be updated wrt new
  text (RFCs 3667, 3668).
3) Abstract should still expand PSTN - I asked that
  SPIRITS be expanding, I should have explicitly asked
  for the PSTN to be expanded.
4) Still no IPR section.

[Ballot comment]
I am not entirely happy with the state of this draft, but do not see reason to create additional blockage. The comments below should be sent to the authors with the DISCUSS comments from other ADs.

Review from John Loughney, Gen-ART reviewer:

I have been unable to fully review this document.  Part of the problem may
be due to the draft itself - having the flu hasn't helped.  I cannot say this
document is ready for publication, mostly because of my confusion when
reading the document.  I don't feel that the document is clearly written.
However, I think this work would have little impact directly upon the
health of the Internet, so it might be reasonable not to be overly
strict in a review.

Some background - I spent the early part of the 90's implementing IN
in PSTN switches, so I have a basic familiarity with the subject area.
I sat in several SPIRITS meetings, but decided that this wasn't entirely
productive use of my time.

Some comments, in an a somewhat random order.  Please note that I have
not had a chance to go through in great detail the main body of the
text - I am still having a hard time getting around all of the details
contained.

1) Formmating is off.

2) First usage of SPIRITS in the abstract should be expanded.

3) First major confusion, the abstract says:

  ".... Internet Call Waiting, Internet
  Caller-ID Delivery, are examples of SPIRITS services; as are
  location-based services on the cellular network.  The protocol is to
  define the building blocks from which many other services can be
  built."

  But the document seems to define 2 SIP event packages and an XML
  based schema for some services.  The document defines call related
  events and gives examples, but this doesn't really seem like a
  protocol to me.

4) nit:

  "... The term Public
  Switched Telephone Network (PSTN) is used here to include all manner
  of access; i.e. wireline circuit-switched network as well as the
  wireless circuit-switched network."

  "All manner of access"? Does this include IP? Avian carriers?

5) nit:

  ".... In general terms, an Internet host will express an interest in
  getting notifications of certain events occurring in the PSTN."

  How does an Internet host express interest?  Buying the PSTN a drink?

6) First full paragraph on page 6 brings up a lot of terminology like 
  "SPIRITS client", "SPIRITS server" - a terminology section would be nice.

7) Page 39 - changes section should be removed upon publication as an RFC.

8) Acronym section on page 39 should be moved up-front.

9) Normative references section should probably contain some references
  to the basic call state model in the PSDN.  A reference to a book writen
  by one of the draft's co-authors seems a bit dodgy.  Rather should reference
  ITU-T or ANSI specs on IN.

  [2] Faynberg, I., L. Gabuzda, M. Kaplan, and N.Shah, "The Intelligent
  Network Standards: Their Application to Services", McGraw-Hill, 1997.

10) Needs IPR text.

[Ballot comment]
I've given a careful (though I'm sure additional) review to the event package and MIME registrations.  They look fine.

Typo:
  This request eventually arrives at the SIPRITS notifier

It's nice to know the wg maintained constantly solidarity :)

[Ballot comment]
I've given a careful (though I'm sure additional) review to the event package and MIME registrations.  They look fine.

Typo:
  This request eventually arrives at the SIPRITS notifier

[Ballot discuss]
In addition to Scott's mention of well-formed (or not) comments, I ran the schema through a schema validator and have additional concerns.  Note that I know absolutely nothing about schema.

 

is missing an  ..  pair around the elements

   

This is missing the />, so opens an  that is never closed.

       

This is missing the />, so opens an  that is never closed.

There are both simple and complex types both named EventType; the validator that I am using does not permit this.  (Here enters my ignorance of whether it's the schema or the validator that's wrong here.)

I haven't done anything to determine whether or not the schema actually represents what's in the document, but it'd be nice if it at least was valid XML and/or a syntactically correct Schema.

[Ballot comment]
The introduction says:

"PSTN is used here to include all manner
  of access; i.e. wireline circuit-switched network as well as the
  wireless circuit-switched network."

There are wireless networks which are not circuit switched, and it is not clear
whether this is meant to imply that they would use these mechanisms.
PSTN has a pretty standard definition in any case, and I'm not sure what
*technical* reason it servers to expand it here.  This is repeated several
other places (overview, eg.).

The use of the URN namespace registered seems to miss the point; they
register the namespace, but then use the top level namespace for
the xml scheme.  As Scott's DISCUSS points out, that makes versioning difficult,
and using urn:ietf:params:xml:ns:spirits:event-package:1 might
resovle that.

This language also is imprecise enough that I would like to see it cleaned up:

  A SPIRITS notifier MAY use an extended schema to generate an XML
  document; however, such an XML document MUST contain the mandatory
  elements defined by the base notification schema.  This assures that
  a vanilla SPIRITS subscriber is, at the bare minimum, able to parse
  and interpret the mandatory elements from an XML document.  The base
  schema assures interoperability across vendor implementations, and
  the extensions allow for customization.

The spirits subscriber must somehow know that the extended schema's
elements are those from the base notification schema.  If I read this
correctly, they intend for these extensions to occur by the base schema
being reused by all vendors and the extensions occurring in other schemas;
that's fine.  But the language above could be read by our embrace-and-extend
friends as "reuse these elements in your own schema and you'll be fine", which
breaks interoperability (essentially saying "these element names are always
subject to the same rules, despite the namespace declaration"--which means
the standard XML view isn't followed).

I'm a no-ob on this only because I think Scott would be better as the token
holder for fixing this.

In 5.3.1, does this:


  A subscriber will issue a SUBSCRIBE request which identifies a set of
  events (DPs) it is interested in getting the notification of.  This
  set MAY contain exactly one DP, or it may contain multiple DPs.  The
  SUBSCRIBE request is routed to the notifier, where it is accepted,
  pending a successful authentication.

mean that it MUST contain at least one DP?

[Ballot comment]
The introduction says:

"PSTN is used here to include all manner
  of access; i.e. wireline circuit-switched network as well as the
  wireless circuit-switched network."

There are wireless networks which are not circuit switched, and it is not clear
whether this is meant to imply that they would use these mechanisms.
PSTN has a pretty standard definition in any case, and I'm not sure what
*technical* reason it servers to expand it here.  This is repeated several
other places (overview, eg.).

[Ballot comment]
Section 2: s/a a "SPIRITS client"/a "SPIRITS client"/

  Section 3: s/This assures that/This ensures that/

  Section 3: s/The base schema assures/Use of the base schema ensures/
 
  I find the formatting in Section 4 difficult.  Indenting would really help.
  I suggest something like:
 
    The  element

      The root of a SPIRITS XML document (characterized by a Content-Type
      header of "application/spirits-event+xml">) is the ...

[Ballot discuss]
In Section 7.2, the MIME type registration points to the wrong section:
  >
  >  Security considerations: section 10 of [9] and section 7 of this
  >  document.
  >
  This ought to point to section 8, not section 7.
 
  Section 8 says that the use of S/MIME will alleviate privacy and fraud
  concerns.  I understand how privacy concerns are addressed by the S/MIME
  encryption capability.  On the other hand, fraud concerns need more
  explanation.  Further, the security considerations section of [5] does
  not offer any assistance.  It never uses the word "fraud."

  I believe that it would be useful for Section 8 to discuss the trust
  anchors that are needed to validate the CMS SignedData.  Since the
  authors believe that the B and C interfaces are likely to be owned by
  the same organization, it is quite possible that public keys will be
  installed in the two SPIRITS endpoints, eliminating the need for X.509
  certificates.  This approach requires the implementations to support
  the subjectKeyIdentifier optional feature.

[Ballot discuss]
RFC 2119 is mentioned in section 1.1, but it's not cited.  It should be a normative reference.

This document registers an XML namespace and requires conformance with an XML schema specified in the document, but it does not describe how versioning will be accomplished.  It would be wise to either include a version number in the namespace declaration/registration or add text to describe how XML versioning will be accomplished -- or if it is prohibited (which might be unrealistic).

Section 7.3: An IETF working group should not be identified as the registrant as the WG can not be expected to be around forever.  RFC 3688 says that "the Registrant will be the IESG".

I would also suggest registering the schema provided in section 9 as described in section 3.2 of RFC 3688.

I also found some errors in the XML provided in the document:

Section 4: The 5551212 elements are improperly terminated.  is used where  is required.

Section 9: XML comments can not include internal instances of consecutive hyphen characters ("--").  See http://www.w3.org/TR/2000/REC-xml-20001006#sec-comments

State Changes to In WG                                            from Pre AD Evaluation                                by sob