Subject: [siprec] Comments on draft-ietf-siprec-architecture-03

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 28 Feb 2012 13:42:16 +0200

Hi,

some comments on the architecture draft:
http://tools.ietf.org/html/draft-ietf-siprec-architecture-03

All acronyms need to be expanded on their first use. Also, the use of
acronyms need to be consistent throughout the document. For example, in
Section 3.1.1 in some cases the acronym appears without its expansion,
in other cases the expansion appears without the acronym, and in other
cases both appear together.

In Section 2 (Definitions), there is a definition of a Recording aware
UA. For completeness, the text should talk about recording unaware UAs
as well, either as part of the same definition of as a new term.

Also in that definition:
  s/notify the SIP UA/notify the Recording aware UA/
  s/all the SIP UA/all the Recording aware UAs/

The definition of Replicated Media needs to explain its relation with
the Recording Session (RS).

Section 3.1.1, 4th paragraph:
  s/will need to contain/contains/

Section 3.1.2, 3rd paragraph. The text could touch upon how a RS can
know about an endpoint and about the fact that the endpoint will
establish a session that needs to be recorded at some point. Something
brief would be enough.

Section 3.1.4 talks about the RTCWeb control protocol. The text needs to
be more explicit because it is not clear what protocol that sentence
refers to.

Section 3.2.1, 3rd bullet. The bullet talks about two possible
mechanisms. The text should be more clear on that, given that they are
not just two possible mechanisms out of many. They are the only two
mechanisms defined in the protocol document, one of which is mandatory
(i.e., at a MUST level).

Section 3.2.2 misses a first bullet like the one in Section 3.2.1, about
how the URI of the SRC is provisioned.

Section 3.2.2, 3rd bullet. Why does it say "Possibly"?

The document could include a bit more text explaining what the protocol
document defines so that it is easier for readers to understand what
exactly they will find there.

Cheers,

Gonzalo

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 29 Feb 2012 14:54:38 +0100

Hi Gonzalo,

Thanks for the comments some responses below.

Regards
Andy

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Gonzalo Camarillo
> Sent: 28 February 2012 11:42
> To: [email-masked]
> Subject: [siprec] Comments on draft-ietf-siprec-architecture-03
> 
> Hi,
> 

Agree consistency is always a good idea.

> as well, either as part of the same definition of as a new term.

Ok

>   s/all the SIP UA/all the Recording aware UAs/

Ok

> the Recording Session (RS).

Ok.
> establish a session that needs to be recorded at some point. Something

Ok - I assume when you refer to RS you actually mean SRS. How an SRS knows what and when to record is really out of scope of SIPREC and down to Policy/Configuration in the SRS so that is probably all we can say.

> be more explicit because it is not clear what protocol that sentence

I think it would be best to remove the reference to RTCWeb.

> mechanisms defined in the protocol document, one of which is mandatory

I think this is old text from before we had the protocol draft so we can just remove the options and refer to the protocol draft for the details.

> how the URI of the SRC is provisioned.

Ok.

> Section 3.2.2, 3rd bullet. Why does it say "Possibly"?

Because it is old text intended to start a discussion and actually we have not firmed up on anything here and leave it to policy at the SRC so we should say so. Normally I think the SRS initiated case is related to persistent recording and so there has been no need to define such a mechanism so far.

> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: Leon Portman <[email-masked]>
Date: Wed, 29 Feb 2012 16:37:30 +0200

Gonzalo Hi

I will update the architecture draft accordingly in the next update (hopefully this week).

Thank you for the comments

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hutton, Andrew
Sent: Wednesday, February 29, 2012 3:55 PM
To: Gonzalo Camarillo; [email-masked]
Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-03

Hi Gonzalo,

Regards
Andy

> acronyms need to be consistent throughout the document. For example, 
> in Section 3.1.1 in some cases the acronym appears without its 
> expansion, in other cases the expansion appears without the acronym, 
> and in other cases both appear together.

Ok

Ok

Ok.

> 
> Section 3.1.4 talks about the RTCWeb control protocol. The text needs 
> to be more explicit because it is not clear what protocol that 
> sentence refers to.

> 
> Section 3.2.2 misses a first bullet like the one in Section 3.2.1, 
> about how the URI of the SRC is provisioned.

Ok.

> 
> The document could include a bit more text explaining what the 
> protocol document defines so that it is easier for readers to 
> understand what exactly they will find there.
> 
> Cheers,
> 
> Gonzalo