XML Pipelining with Chunks for the Internet Registry Information Service
RFC 4992

[Ballot discuss]
There is no mandatory to implement security mechanism provided in
section 14.1 as required by BCP 61.3

For the rules about security layers described in section 14.2 to work,
the client must not send any chunks that would need to be protected by
a security layer until it knows that a security layer will or will not
be used.  The fact that you need to block waiting for an
authentication success/failure chunk needs to be clearly stated in section 6.

RFC 4422 section 4 requires that you be able to distinguish empty
initial responses from absent initial responses.  The text needs to
document how this is done.

What are the semantics of non-empty authorization IDs?

RFC 4422 section 4 includes several SHOULDS that this protocol violates.
Please document why you violate these SHOULDs or implement them:

      A protocol SHOULD specify a facility through which the client may
      discover, both before initiation of the SASL exchange and after
      installing security layers negotiated by the exchange, the names
      of the SASL mechanisms that the server makes available to the
      client.  The latter is important to allow the client to detect
      downgrade attacks.  This facility is typically provided through
      the protocol's extensions or capabilities discovery facility.



        This message[authentication success] SHOULD contain an
optional field for carrying
        additional data with a successful outcome.

[Ballot discuss]
Section 5., paragraph 4:
>      session immediately after sending the corresponding response.  In
>      a response block (RSB) or a connection response block (CRB): a
>      value of 1 indicates that the server will keep the TCP session
>      open to receive another request, and a value of 0 indicates that
>      the server will close the TCP session immediately following this
>      block.

  DISCUSS: Forcing the server to close the connection will make it
  accumulate TCP TIME-WAIT state, which can lead to poor performance and
  can be used as a DoS vector. This was a huge issue with HTTP 1.0 in
  the 90s. For a new protocol, it would make a lot of sense to have the
  client close the connection, to offload the TIME-WAIT state from the
  server to the client.


Section 7., paragraph 0:
>    7.  Idle Sessions

  DISCUSS: This basically reimplements the keep-alive feature that most
  TCP implementations have, using a much more aggressive interval (2
  minutes vs. 2 hours.) I fail to see why this is necessary  at all -
  the client can simply re-open a new connection. If the authors feel
  that keep-alives are necessary, please provide a dicsussion/motivation
  along the lines of RFC1122 Section 4.2.3.6.


Section 15., paragraph 10:
>    [10]  Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers",
>          RFC 1166, July 1990.

  DISCUSS: Is a DOWNREF (PS->Informational).

[Ballot discuss]
Section 5:

o  bits 0 and 1 - version (V field) - If 0 (both bits are zero), the
      protocol is the version defined in this document.  Otherwise, the
      rest of the bits in the header and the block may be interpreted as
      another version.

I think it is dangerous to have undefined behavior towards unknown versions. Please define a behavior if a request is received in an unknown version.

Section 5:

o  bit 3, 4, 5, 6, and 7 - reserved - These MUST be 0.

Please define the behavior a receiver should have upon receiving non-zero reserved bits. I find this particular important if one ever tries to use these bits in the future. What rule to set depends on what extension strategy one is after.

section 9.

When using XCPS is that identified differently in the version chunk than regular XCP? The fact that you define a different URI scheme for it indicates that it also should have a unique id for the version chunk XML instance.

[Ballot discuss]
Section 5:

o  bits 0 and 1 - version (V field) - If 0 (both bits are zero), the
      protocol is the version defined in this document.  Otherwise, the
      rest of the bits in the header and the block may be interpreted as
      another version.

I think it is dangerous to have undefined behavior towards unknown versions. Please define a behavior if a request is received in an unknown version.

section 9.

When using XCPS is that identified differently in the version chunk than regular XCP? The fact that you define a different URI scheme for it indicates that it also should have a unique id for the version chunk XML instance.


Section 5:

o  bit 3, 4, 5, 6, and 7 - reserved - These MUST be 0.

Please define the behavior a receiver should have upon receiving non-zero reserved bits. I find this particular important if one ever tries to use these bits in the future. What rule to set depends on what extension strategy one is after.

[Ballot discuss]
Section 5:

o  bits 0 and 1 - version (V field) - If 0 (both bits are zero), the
      protocol is the version defined in this document.  Otherwise, the
      rest of the bits in the header and the block may be interpreted as
      another version.

I think it is dangerous to have undefined behavior towards unknown versions. Please define a behavior if a request is received in an unknown version.

Section 5:

o  bit 3, 4, 5, 6, and 7 - reserved - These MUST be 0.

Please define the behavior a receiver should have upon receiving non-zero reserved bits. I find this particular important if one ever tries to use these bits in the future. What rule to set depends on what extension strategy one is after.

[Ballot discuss]
Section 5:

o  bits 0 and 1 - version (V field) - If 0 (both bits are zero), the
      protocol is the version defined in this document.  Otherwise, the
      rest of the bits in the header and the block may be interpreted as
      another version.

I think it is dangerous to have undefined behavior towards unknown versions. Please define a behavior if a request is received in an unknown version.

IANA Last Call comments:

As requested in the IANA Considerations section, upon approval of this document
IANA will complete three actions:

1) Registration of two new URI schemes:
iris.xpc and
iris.xpcs
in the Permanent URI scheme registry located at:
http://www.iana.org/assignments/uri-schemes.html

2) Registration of two new S-NAPTR application protocol tags:
iris.xpc and
iris.xpcs
in the S-NAPTR application protocol tag registry located at:
http://www.iana.org/assignments/s-naptr-parameters

3) Registration of two new well-known TCP port numbers:
iris.xpc and
iris.xpcs
in the IANA Port Number Registry located at:
http://www.iana.org/assignments/port-numbers

IANA understands that there are no other IANA Actions for this document.