Subject: tsv-dir review of draft-ietf-mile-rfc4046-bis-05

From: Mark Allman <[email-masked]>
Date: Wed, 11 Jan 2012 08:52:50 -0500

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-masked] 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.

(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.

allman

---

From: Mark Allman <[email-masked]>
Date: Thu, 12 Jan 2012 12:34:53 -0500

> 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.

That is what I was thinking.  I.e., I was not suggesting some way to
discover the port or whatnot.  Just not mandating that all communication
happen on the assigned port (which of course you could never do
regardless of what the RFC says).

Sounds like a good set of changes to me.

allman

---

From: Brian Trammell <[email-masked]>
Date: Thu, 12 Jan 2012 10:22:25 -0600

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...

>    exact).  It would seem useful to me to clean this up.

Agreed completely, and done.

>    that leveraged late binding would strikes me as more flexible and

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)