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

[Gunnar Hellström <[e-mail]>]

Mahesh,

Your review brings up interesting aspects.

I can provide some initial responses,


Den 2017-03-07 kl. 03:47, skrev Mahesh Jethanandani:
> 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?
In section 5 of RFC 4566 the SDP specification, it is said:
"An SDP parser MUST ignore any attribute it doesn't understand."

In a real world, the deployment will be gradual, so many times, either 
the caller UA or the callee UA will not understand these attributes.

Some possible default actions are mentioned in the draft for cases when 
there are no settings or no support in either end, but the draft is not 
intended to provide exact solutions for the negotiation, but rather only 
provide a protocol for conveying indications sufficient for performing 
the negotiation.
>
> What is the impact on network operations if for example either the
> translator or relay agent fails? How would that impact the
> negotiation?
The draft does not intend to dictate how and by what party a 
language/modality gap is detected, so that a translating agent or 
modality conversion relay service will be desired and invoked in the 
call. The intention is to make such detection and invocation possible, 
at least regarding relay services. The natural way of using the 
mechanism of the draft is that each party involved in the call setup 
will modify the hlang attributes to indicate the joint capabilities and 
preferences of the so far involved parties. If invocation of a party 
fails, its modification of the hlang attributes does not take place and 
the answer will then not likely contain a satisfying set of languages 
for the offering party. This may be a case when the paranthesis in this 
sentence in section 5.2 comes into play: "In an answer, 'hlang-send' is 
the language the answerer will send
    when using the media (which in most cases is one of the languages in
    the offer's 'hlang-recv'), and 'hlang-recv' is the language the
    answerer expects to receive in the media (which in most cases is one
    of the languages in the offer's 'hlang-send')."

If the answering party was the one who intended to invoke the 
translation or relaying if needed, then it can also deny the call if 
that is indicated as a preference in the incoming call.

These details belong to the negotiation mechanism that was not intended 
to be described in detail in the draft.
>
> 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.
Interesting aspects. Let us see what others say about what we can 
include at this stage and what should be brougth up in follow-up documents.

/Gunnar
>
> Idnits:
>
> A run of idnits came out clean.
>
>
>
> _______________________________________________
> SLIM mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/slim

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[e-mail]
[phone]