Yes. I just replied to Dan’s comment. Will take care of all of them. Thanks for
From: Jari Arkko <jari.ar...@piuha.net>
Date: Thursday, 1 December 2016 at 7:08 PM
To: Dan Romascanu <droma...@gmail.com>
Cc: <firstname.lastname@example.org>, <draft-ietf-siprec-callflows....@tools.ietf.org>
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-siprec-callflows-07
Resent-From: <alias-boun...@ietf.org>, <jari.ar...@piuha.net>
Resent-To: <rmoh...@cisco.com>, <par...@parthasarathi.co.in>,
<pkyzi...@alum.mit.edu>, <andrew.hut...@unify.com>, <b...@brianrosen.net>,
<b...@nostrum.com>, <ali...@cooperw.in>, <aamelni...@fastmail.fm>, Andrew
Hutton <andrew.hut...@unify.com>, <draft-ietf-siprec-callflows....@ietf.org>
Resent-Date: Thu, 1 Dec 2016 05:38:11 -0800
Thank you very much for your review, Dan. Authors, have you taken a look at
On 25 Nov 2016, at 14:16, Dan Romascanu <droma...@gmail.com> wrote:
> 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 wait for direction from your
> document shepherd or AD before posting a new version of the draft.
> For more information, please see the FAQ at
> Reviewer: Dan Romascanu
> Review Date: 11/25/16
> IETF LC End Date: 11/27/16
> IESG Telechat date: (if known) 12/2/16
> Summary: Ready.
> This is a very useful supporting document in the SIPREC cluster.
> Major issues:
> Minor issues:
> Nits/editorial comments:
> 1. The title is slightly misleading, as the document does not have as
goal to document all or the most important call flows, but rather to provide a
grouping of significant examples. 'Examples of SUP Recording Call Flows' may
have been a better title.
> 2. As the document uses terminology defined in [RFC7865] and [RFC6341],
listing these two RFCs as Normative References seems necessary (can't
understand the terms without reading the two RFCs)
> 3. typo in the Securoty Considerations section: '
> Security considerations mentioned in [RFC7865] and [RFC7866] has to be
> s/has to/have to/
> Gen-art mailing list
Gen-art mailing list