[Slim] Alvaro Retana's No Objection on draft-ietf-slim-negotiating-human-language-19: (with COMMENT)

[Alvaro Retana <[e-mail]>]

Alvaro Retana has entered the following ballot position for
draft-ietf-slim-negotiating-human-language-19: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for writing an interesting document!

Given that this document doesn’t mandate the behavior in the case of not having
languages in common, why does it matter if the combination is “difficult to
match together” or not?  I’m wondering about this piece of text (from 5.2):

   ...The
   two SHOULD NOT be set to languages which are difficult to match
   together (e.g., specifying a desire to send audio in Hungarian and
   receive audio in Portuguese will make it difficult to successfully
   complete the call).

I don’t understand how “difficult to match” can be enforced from a normative
point of view.  Difficulty seems to be a subjective criteria -- the example
shows a pair that I would consider difficult too (I don't speak Hungarian!),
but other pairings could still be difficult for me but easy for others.  Using
“SHOULD NOT” (instead of “MUST NOT”) implies that there are cases in which it
is ok to do it (again, probably subjectively).  It seems to me that the “SHOULD
NOT” could be a simple “should not”.

BTW, that reminds me: please use the template text from rfc8174 (instead of
rfc2119).

Nit:  It would be nice to expand SPD in the abstract and put a reference to
rfc4566 in the Introduction.