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

[Robert Sparks <[e-mail]>]

(As an individual contributor)

Following up on:

> 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

Here is some proposed text that could replace the description of Table 1 and Table 1
itself in section 8.2:

In the following cases, an element will not have a sensical value to provide
for one of these fields, even though the field is mandatory. For these cases, the
encoding of the model must define how to represent "not applicable". The R-URI
field is not applicable when logging a response. The Status field is not applicable
when logging a request.

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.