[Slim] Review of draft-ietf-slim-negotiating-human-language-08

[Mahesh Jethanandani <[e-mail]>]

Reviewer: Mahesh Jethanandani
Review result: Has Nits

I have reviewed this document as part of the Operational
directorate’s ongoing effort to review all IETF documents being
processed by the IESG.  These comments were written with the intent of
improving the operational aspects of the IETF drafts. Comments that
are not addressed in last call may be
included in AD reviews during the IESG review.  Document editors
and WG chairs should treat these comments just like any other last
call comments.

Document reviewed:  draft-ietf-slim-negotiating-human-language-08

Status:

Ready with comments.

Summary: 

This document adds new SDP media-level attributes so that when
establishing interactive communication sessions ("calls"), it is
possible to negotiate (communicate and match) the caller's language
and media needs with the capabilities of the called party.

The document is short and easy to read. And it seems to have
considered many aspects of trying to negotiate a common human language
or capability. This review looks at the document more from a operator
or management perspective. 

Operational considerations:

>From a operations perspective, there may be a need to troubleshoot the
interface that sets up the negotiated human language. Identifying
consistent methods of information that should be counted by both
parties will go a long way in debugging a problem. For example, in
this case, it would be helpful to start by collecting how many
requests were made, how many found a language or medium in common and
how many were rejected because a common match was not found.

Management considerations:

The old adage says, “Anything that can be configured, can also be
misconfigured”, unless that is somehow made less possible by providing
default values, modes or parameters. This can be something that can be
defined using a data model in YANG.

I assume that the default behavior of receiving a SDP attribute that
one does not support, results in a throw away of that particular
attribute, and not the whole message, if combined with other
attributes. Is this documented somewhere? If not, what does the
deployment scenario look like, particularly with existing solutions?

What is the impact on network operations if for example either the
translator or relay agent fails? How would that impact the
negotiation?

Also, what is the test, both active and passive for the correct
operation? Is there a counter being maintained for both correct and
incorrect negotiation. Goes back to the question of what counters are
being maintained. Such counters should include values that enable
isolation of faults. For example, if negotiation fails, what are the
more specific counters that isolate what within the negotiation
failed?

Fault Management:

In addition to collection information on how the negotiation is
working, it is important to be able to propagate both fault and health
indicators to a management application. Such information needs to be
documented.

Accounting Management:

Finally, it is always helpful to collect information on utilization
from capacity, trend analysis, cost allocation, auditing and billing
perspective.

Idnits:

A run of idnits came out clean.