Hi, Mark, Thanks for the review; I've addressed these issues in an -06 revision to be submitted after last call is complete. Comments thereon, inline...
On Jan 11, 2012, at 7:52 AM, Mark Allman wrote: > > I've reviewed this document as part of the transport area directorate's > ongoing effort to review key IETF documents. These comments were written > primarily for the transport area directors, but are copied to the > document's authors for their information and to allow them to address > any issues raised. The authors should consider this review together with > any other last-call comments they receive. Please always CC > [email protected] if you reply to or forward this review. > > This draft is basically ready for publication, but has nits that should > be fixed before publication. > > In reading this document I flagged two issues. Neither of them huge, > but I'd think perhaps they should be addressed before publication. > > (1) The language is a little wonky in my opinion. The document is > laying out a 'transport protocol'. But, while this protocol does > transport bits of data this is absolutely not a layer 4 protocol and > so I was initially a bit confused. This draft lays out an > application layer protocol (a slightly tweaked version of HTTP to be > exact). It would seem useful to me to clean this up. Agreed completely, and done. > (2) I wondered why the document said hosts MUST use port 4590. > Certainly having a well know port is useful in many cases. But, I > don't see why some consortium couldn't decide they were going to use > port 4545 or whatever. Likewise, when setting up a callback it'd > seem straightforward to give a port number, as well. > > I am not sure it is the biggest deal in the world, but a solution > that leveraged late binding would strikes me as more flexible and > hence better. Agreed that the restriction is too strict. However, I think it's simpler at this point to declare the use of ports other than the well-known port to be configurable out of band, as other RID system and consortium configuration issues are out of scope for this document as well. So, the clarifying text would be as follows: Every RID system participating in a consortium SHOULD listen for HTTP/TLS connections on the assigned port. RID systems MAY be configurable to listen on ports other than the well-known port; this configuration is out of band and out of scope for this specification. and When performing RID callback, a responding system MUST connect to the host at the network-layer address from which the original request was sent; there is no mechanism in RID for redirected callback. This callback SHOULD use TCP port 4590 unless configured out of band to use a different port. Many thanks, best regards, Brian (as 6046-bis author)
