Re: [AVTCORE] [Last-Call] Genart last call review of draft-ietf-avtcore-multi-party-rtt-mix-14

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

Peter,

I have made the extra few adjustments you proposed.

For the use of "disappeared", I agree that it is an unusual term in this 
context.

I checked RFC 4575, and there it is said that users "depart" or 
"disconnect" from a conference. "Disconnect" feels most familiar, so I 
propose to change the sentence to:

"When a participant on the RTP side is disconnected from the multiparty 
session, the corresponding T.140 data channel(s) SHOULD be closed."

Thanks,

Gunnar

-- 

Gunnar Hellström

GHAccess

[e-mail]  <mailto:[e-mail]>


Den 2021-05-07 kl. 20:55, skrev Peter Yee:
> Thanks for the quick response, Gunnar. I've prefaced my replies below with [PEY].
>
> 		-Peter
>
> -----Original Message-----
> From: Gunnar Hellström [mailto:[e-mail]]
> Sent: Thursday, May 06, 2021 2:14 PM
> To: Peter Yee; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: Genart last call review of draft-ietf-avtcore-multi-party-rtt-mix-14
>
> Thank you for the thorough review. Please see comments inline.
>
> I will split the answers, and start here with answers and change
> proposals for the minor issues:
>
> Den 2021-05-06 kl. 05:41, skrev Peter Yee via Datatracker:
>> Reviewer: Peter Yee
>> Review result: Ready with Issues
>>
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair.  Please treat these comments just
>> like any other last call comments.
>>
>> For more information, please see the FAQ at
>>
>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>>
>> Document: draft-ietf-avtcore-multi-party-rtt-mix-14
>> Reviewer: Peter Yee
>> Review Date: 2021-05-05
>> IETF LC End Date: 2021-05-03
>> IESG Telechat date: Not scheduled for a telechat
>>
>> Summary: This draft specifies updates to RFC 4103 to allow real-time text
>> mixing for both multiparty-aware and multiparty-unaware participants. It has
>> some minor issues that should be addressed before publication. [Ready with
>> issues]
>>
>> Major issues: None
>>
>> Minor issues:
>>
>> Page 7, 1st block, 13th sentence: what constitutes a “reasonable effort”? It
>> might be best to drop this sentence.
> [GH] This reason is important for the desicion on technology selection.
>
> I suggest a change from:
>
> "For best deployment opportunity, it should be possible to upgrade
> existing endpoint solutions to be multi-party aware with a reasonable
> effort."
>
> to
>
> "For best deployment opportunity, it should be feasible to upgrade
> existing endpoint solutions to become multiparty-aware."
>
> [PEY] I'm fine with that.
>
>> Page 7, 2nd block, 2nd sentence, “300 ms”: would it make sense to append
>> “period” or “timeout” after this value?
> [GH] I suggest to change from "every 300 ms." to "with 300 ms intervals."
>
> [PEY] Works for me.
>
>> Page 13, section 3.4, 2nd paragraph, 1st sentence: in regards to “only part”,
>> how is this calculated?
> [GH] I suggest to change from "If the "CPS" value is reached, longer
> transmission intervals SHALL be applied and only part of the text queued
> for transmission sent at end of each transmission interval, until the
> transmission rate falls under the "CPS" value again."
>
> to
>
> "If the "CPS" value is reached, longer transmission intervals SHALL be
> applied and only as much of the text queued for transmission sent at end
> of each transmission interval that can be allowed without exceeding the
> "CPS" value, until the transmission rate falls under the "CPS" value
> again. Division of text for partial transmission MUST then be made at
> T140block borders. "
>
> [PEY] That's clearer. I'd insert "the" before "end".
>
>> Page 15, section 3.12, 2nd paragraph, 1st sentence: The placing of all
>> available redundant levels in the packet is presumably subject to a maximum
>> packet size or the “CPS” limit, if there are obnoxious levels of redundancy
>> specified?
> [GH] Thanks, a good observation. It is already covered in section 3.10,
> but it could be more emphasized there. In 3.12 we are only dealing with
> the redundancy, which must be possible to send and is not included in
> the "CPS" value.
>
> I suggest that the following part of 3.10 is improved from:
>
> "Redundant text SHALL also be included.  See Section 3.12"
>
> to;
> "Redundant text SHALL also be included, and the assessment of how much
> new text can be included within the maximum packet size MUST take into
> account that the redundancy has priority to be transmitted in its
> entirety.  See Section 3.12."
>
> [PEY] That works.
>
>> Page 17, section 3.17.2, 4th paragraph, 2nd sentence: “SHALL prefer” seems odd.
>> It doesn’t say that the marking will actually be done. It’s just preferred. If
>> you’re not going to require the marking in that sentence, then perhaps change
>> “SHALL” to “SHOULD”.
> [GH] Agreed. Done as proposed.
>> Page 19, section 3.20, 2nd paragraph, 2nd sentence: I don’t find the “something
>> specific” particularly enlightening. Like what? An identifier for the method?
> [GH] Proposed to be changed from:
>
> " In that case, the
>      SDP of the offer will include something specific for that method, and
>      an answer acknowledging the use of that method would accept it by
>      something specific included in the SDP."
>
> to:
>
> "In that case, the
>      SDP of the offer will include something specific for that method,
> e.g. an SDP attribute or another media format. An answer selecting the
> use of that method would accept it by
>      a corresponding acknowledgement included in the SDP."
>
> [PEY] That helps. With a comma after the "e.g.". ;-)
>
>> Page 27, section 4.2.2, 4th paragraph: can you elaborate on these “Integrity
>> considerations”? Otherwise, it’s difficult to comply with the SHALL in any
>> meaningful way.
> [GH] The sentence was inserted after discussions with emergency service
> providers, who had an example that it would be valuable to have a
> detailed personalized label of an emergency service agent shown to other
> agents while a less personal label should be used when sent to the
> calling users in emergency.
>
> The security aspects on the label are quite similar to the security
> aspects on the <display-text> elements specified in RFC 4575. Its
> security aspects are specified in
> https://tools.ietf.org/html/rfc4575#section-8
>
> You are right that that example contains mainly SHOULD and RECOMMENDED
> and no SHALL.
>
> I suggest changing:
>
> "Integrity considerations SHALL be taken when composing the label."
>
> to:
>
> "Information available to the mixer for composing the label may contain
> sensitive personal information that SHOULD not be revealed in sessions
> not securely authenticated and protected. Integrity considerations
> regarding how much personal information is included in the label SHOULD
> therefore be taken when composing the label."
>
> [PEY] That's much clearer.
>
>> Page 33, 3rd paragraph, 1st sentence: any reason for the change from “T.140” in
>> the previous and following paragraphs to “t140” in this one?
> [GH] No, they should be "T.140 data channels" for all cases in that
> paragraph.
> I have changed.
>> Page 33, 6th paragraph: how is disappearance determined?
> [GH]The disappearance may be signaled by the SIP conference system RFC
> 4353, RFC 4575 etc. as a conference notification if that system is used,
> or simply by removal of the text media in an RTP session modification.
> There may also be a malfunction detected by keep-alive transactions not
> being maintained. I suggest to not detail how it disappears.
>
> [PEY] Okay by me if that's well understood in this ecosystem. The verb disappearance just made it sound somewhat mysterious as opposed to something that can be signaled.
>> Page 35, section 11, 3rd paragraph, 2nd sentence before creating a new sentence
>> (see nits, below): I’m having troubles tying the adjective “secure” to each of
>> the nouns in the sentence. It works for “signaling” and perhaps “media”, but
>> for “authentication”, one sort of assumes that authentication mechanism is
>> secure and helping to provide the security. Perhaps you could reword that
>> sentence?
> [GH] I propose to change the sentence from:
>
> "Counteractions should be to require
>      secure signaling, media and authentication, and to provide higher
>      level conference functions e.g. for blocking and expelling
>      participants."
>
> to:
>
> "Counteractions should be to require authentication, secure session
> signaling and secure media. Higher level conference functions should
> also be used e.g., for blocking and expelling participants who caused
> security concerns."
>
> [PEY] Yes, I like that. Along with my usual nit about an Oxford comma after "signaling". And a hyphen between "Higher" and "layer". Sorry, that's just how my eyes/brain work. ;-)
>
>
> Thanks,
>
> Gunnar Hellstrom
>
-- 
Gunnar Hellström
GHAccess
[e-mail]