A Common Schema for Internet Registry Information Service Transfer Protocols
draft-ietf-crisp-iris-common-transport-05

[Ballot discuss]
Steve Bellovin posted a SecDir Review on 5-Sep-2006.  It was sent to
  the IESG and to andy@hxr.us.  I have not seen a response to the
  concerns that were raised in the review.  One of Steve's concerns is:
  >
  > I am very concerned that this document underspecifies certain vital
  > information, including security-critical fields.  Broadly speaking,
  > there is no discussion of how applications should interpret a
  > version assertion, especially if it is not an exact match to one
  > known to the far side. (IKEv2 had this problem, because the original
  > IKE spec didn't say anything on the subject.)
  >
  Please add a paragraph to section 4 to address this concern.

[Ballot discuss]
This doesn't contain text explaining whether implementations can add new elements or attributes to the XML "versions" document on the wire.  If that is disallowed, the document should say so.  If that is allowed, then I suspect one of our routine warnings about not using strict validation (and thus breaking extensibility) is warranted here.

I don't understand why this document has informative references to the base IRIS stuff; it is unimplementable and certainly untestable without other protocol pieces beyond what's covered in the normative references.  The reference to RFC3891 should be RFC3981 (and there are other broken pointers in the references).

[Ballot discuss]
This doesn't contain text explaining whether implementations can add new elements or attributes to the XML "versions" document on the wire.  If that is disallowed, the document should say so.  If that is allowed, then I suspect one of our routine warnings about not using strict validation (and thus breaking extensibility) is warranted here.

[Ballot discuss]
I fail to understand how this schema can be used in any protocol or why the information within it is common between IRIS application transports. I have read through everything concerning the transport parts in RFC 3981. I still don't understand what purpose this documents fullfils. I might be missunderstanding things here. However, as I see it this document need some amount of text that explains how it relates to both the core protocol and any transports defined.

[Ballot comment]
Informative Reference list:

[8]  Newton, A. and M. Sanz, "Internet Registry Information
        Service", RFC 3891, January 2004.

RFC 3891 is: The Session Initiation Protocol (SIP) Replaces Header

[Ballot comment]
I don't think this specification provides enough detail that it
guarantees interoperable implementations.  There is not sufficient
mandatory behavior.  I also disagree that this spec represents an
appropriate decomposition of the problem space.  It seems based on
textual reuse rather than some abstraction in the problem domain.

[Ballot discuss]
Steve Bellovin posted a SecDir Review on 5-Sep-2006.  It was sent to
  the IESG and to andy@hxr.us.  I have not seen a response to the
  concerns that were raised in the review.  One of Steve's concerns is:
  >
  > I am very concerned that this document underspecifies certain vital
  > information, including security-critical fields.  Broadly speaking,
  > there is no discussion of how applications should interpret a
  > version assertion, especially if it is not an exact match to one
  > known to the far side. (IKEv2 had this problem, because the original
  > IKE spec didn't say anything on the subject.)
  >
  Please add a paragraph to section 4 to address this concern.

  Steve also said:
  >
  > There is no citation for where language tags (Section 6 and 7)
  > come from.  The same is true of authenticationIds, protocolId,
  > and I suspect several others.
  >
  The document needs to say where these identifiers are registered.  Is
  an IANA registry needed?

IANA Last Call Comments:

Upon approval of this document, the IANA will make the following assignments
in the "NS" registry located at
http://www.iana.org/assignments/xml-registry/ns.html


ID URI Registration Reference
Iris-transport urn:ietf:params:xml:ns:iris-transport see below RFC-iris-
common-transport

-----

Registration template:
o XML Namespace URN/URI:

* urn:ietf:params:xml:ns:iris-transport

o Contact:

* Andrew Newton

o XML:

* None.

o XML Schema URN/URI:

* urn:ietf:params:xml:schema:iris-transport

o Contact:

* Andrew Newton

o XML:

* The XML Schema specified in Section 3 of [RFC-iris-common-transport]

---

We understand the above to be the only IANA Actions for this document.