[Sip] Review of draft-ietf-sip-hop-limit-diagnostics-03

["Vijay K. Gurbani" <[e-mail]>]

Scott:

I went through draft-ietf-sip-hop-limit-diagnostics-03; here
are my comments on the draft.  I went through the existing
WG list discussions regarding this draft to make sure that I
was not duplicating any items that have already been discussed.
To the best of my knowledge, the following have not yet been
discussed.

1) In Montreal, I had mentioned to you that the ICMP sends back
  more than 64 bits of original datagram, and that maybe 64 "bits"
  was transcribed in error.  As it turns out, rfc792 does indeed
  say 64 bits of orgininal datagram.

  However, in practice, we have observed far more data is returned
  from the original datagram than 64-bits.  RFC1122 allows
  implementations to send more than 8 octets (see Section 3.2.2 of
  rfc1122).  So... what we have observed is that Linux returns 520
  bytes of the original datagram, and Solaris returns 64 bytes;
  but for Solaris, this is configurable in the kernel.

  And ICMPv6 (rfc2463) tries to fit as much of the original
  datagram without exceeding the minimum IPv6 MTU in the ICMP
  message.

  So, what does this all mean to hop-limit-diagnostics-03?
  Probably no changes, but interesting and relevant background
  information if you will like to maintain it in the text.

2) Section 3.1, third paragraph talks about removal of "Via
  and Route headers".  I think you meant Record-Route headers
  instead of (or in addition to?) Route headers.  In a
  dialog-establishing INVITE, there'll be greater chances of
  Record-Route headers being present than Route headers (which,
  if they are present consists of a pre-loaded Route set).
  Moreover, the Route headers would be consumed at every hop
  thereby reducing the size of the message, whereas the R-R
  headers are inserted, thus increasing the size.

  It seems that we ought to preserve the Via headers as much
  as possible, at the expense of R-R or Route headers.  The
  Vias give diagnostic information on which intermediaries
  have handled the request, which is of interest.  The Route header,
  on the other hand, portends which intermediary will handle
  the request beyond the element that generated a 483.

3) Nit: Section 3.1, third paragraph, first sentence is
  incomplete.  It states, "...acceptable; the only exception to
  this rule is when ."

4) In the SIP messages, headers that continue should be
  indented (LWS).  The Via headers, for instance, contain a
  branch parameter that begins on a new line without the
  continuation LWS.

5) Section 5 appears to lay the legal groundwork for why a
  UAC should accept a response that contains a body for which
  the UAC did not express an interest in receiving.  I think
  this is good to have.  I would change the first sentence
  of the second paragraph to read as follows:

    Note that a UAC MUST be prepared to receive message bodies
    that it does not understand and did not request in a
    response; this is ...

  That is, move the object of what the UAC must be prepared to
  do closer to the UAC.

6) In Section 6, it appears that the 483 response has been
  pruned, although the text does not indicate so.  By my
  count, if the UAC started with a M-F of 9, then it should
  have 9 Via headers, whereas the example shows the number
  of Via headers to be 7.  You may just want to simply mention
  that the request has been pruned in the response.

Other than that, I am glad that the draft is out -- need
this stuff.

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Bell Laboratories, Lucent Technologies, Inc.
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip