Re: [sip-clf] AD review: draft-ietf-sipclf-problem-statement-07

[Robert Sparks <[e-mail]>]

Hi Vijay  -

Thanks for the updated draft - comments inline and at the end.

On Nov 10, 2011, at 10:19 AM, Vijay K. Gurbani wrote:

> On 08/04/2011 04:06 PM, Robert Sparks wrote:
>> Summary: There are a few issues to address before IETF LC
> 
> Robert: Thank you for your extensive review and suggestions for
> cleaning up the document.  I apologize on attending to your
> comments after a delay, but nonetheless, please see inline
> for more discussions.
> 
> I will submit a revision as soon as the blackout period for
> submitting new I-Ds is lifted on Nov-14.
> 
> > 1) Shouldn't this document be titled something like "framework and
> > data model"?
> 
> We could do so; however, here's a quick history on the draft ... it
> started off life as a problem statement plus solution rolled in one.
> As the work progressed on this, it was deemed more beneficial to
> address issues such as transport and a data model.  Then it was decided
> to spin off the representation format in at least one, possibly two,
> different drafts and have a framework-type approach specified in this draft.
> 
> Through all this, the title of the draft remained as an artifact from
> its origins.  If you'd like me to change it to reflect the framework and
> data model part, I can easily do so.  I do not know whether changing the
> title of a draft midstream will cause any problems to the tools that
> track the draft, but if not, I have no problem changing the title.  As
> I understand it,the name of the draft must remain the same ---
> draft-ietf-sipclf-problem-statement.

It really should change to reflect what the draft really is.
It won't cause problems with the tools.
The filename (draft-ietf-sipclf-problem-statement) does not need to change.
Please issue a revision with this change.


> 
> > 2) Why does this document talk about the 4096 byte limit? Shouldn't
> > this be moved to the encoding draft?
> 
> The consensus to put a 4096 byte limit was reached during WG
> deliberations (see thread starting at [1]).  What was decided during
> this thread was that the problem-statement draft would mandate a
> 4096 byte limit on a SIP record, including bodies.  However, whether or
> not to log a complete body is left up to the specific representation
> draft.  Thus, this 4096 byte limit applies to the existing indexed-
> ASCII representation draft as well as any other representational
> draft that comes along.

So the answer is that this limit is part of the model.

> 
> > 3) The presentation of requirements on devices that forward requests
> > and responses is under-documented. The notion of "UAS-half" is not
> > explained. Looking at what we ended up with for Table 1 from the
> > "new reader" perspective, I suggest that the document doesn't actually
> > need it. The whole section can be simplified with the details focusing
> > on handling R-RUI, Status, Server-Txn, and Client-Txn
> 
> OK, fair enough.  I will adopt the text you had suggested in a follow-up
> email to the list [2], modified slightly to read as follows (this text
> will replace Table 1 in the current draft):
> 
Here's a minor tweak (only a suggestion, feel free to ignore it):
Replace:

>  In the following cases, an element will not have an appropriate
>  value to provide for one of these fields, even though the field
>  itself is mandatory and must appear in the SIP CLF record.  For
>  these cases, the representation document MUST define how to
>  represent such "not applicable" values.  

With:

An element will not always have an appropriate value to provide
for one of these fields, even when the field is required to appear
in the SIP CLF record. Therefore, the representation document
MUST define how to indicate a field is "not applicable".

> For example, the R-URI
>  field is not applicable when logging a response, the Status field
>  is not applicable when logging a request, the To-tag is not known
>  when a request is first sent out, etc.
> 
>  The Client-Txn field is always applicable to a UAC.  The Server-
>  Txn field does not apply to a UAC unless the element is also
>  acting as a UAS, and the message associated to this log record
>  corresponds to a message handled by that UAS.  For instance,
>  a proxy forwarding a request will populate both the Client-Txn
>  and Server-Txn fields in the record corresponding to the
>  forwarded request
> 
>  The Server-Txn field is always applicable to a UAS. The
>  Client-Txn field does not apply to a UAS unless the element is
>  also acting as a UAC, and the message associated to this log
>  record corresponds to a message handled by that UAC. For instance,
>  a proxy forwarding a response will populate both the Server-Txn
>  and Client-Txn fields in the record corresponding to the
>  forwarded response.  However, a proxy would only populate
>  the Client-Txn field when creating a log record corresponding
>  to a request.
> 
> > 4) It is not sufficiently clear what it means when a record MUST
> > contain an element that is not applicable to the element. Are you
> > trying to say "Must be present with a non-empty value that is not a
> > valid value for the field"?
> 
> Yes.
The edit you did for 3 clarified this sufficiently, thanks!
> 
> > (If so, why does it have to be non-empty? The -format- document will
> > eventually need to explain why the group chose "-" there over the
> > empty string.)
> 
> As to why we chose a "-" instead of an empty string --- having a
> printable character appear where an element would have normally
> appeared if it were present is visually helpful for the system
> operators who are observing the SIP CLF records on the screen.

> 
> > 5) There is prose in the definition of the From record field that
<snip/> The rest of this is great - thanks.

One last micro-nit - Can you tune the timestamps in the examples so
that you don't have "missing" retransmissions? For instance, in the
last example, you leave the CANCEL pending long enough that it
should have been resent.

RjS