Subject: [AVT] Adoption of new milestones

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 12 Nov 2010 00:47:37 +0100

(As AVT WG cochair)

We are looking to see if we should adopt a number of new milestones in AVT. This is the adoption of the milestone, not the selection and adoption of an particular draft to fulfil that milestone (that comes later). 

There are four potential new milestones:

-	RTP Header extension for mixer to client audio level indication as proposed standard
-	RTP Header extension for client to mixer audio level indication as proposed standard
-	RTCP indication for retransmission suppression as proposed standard
-	Guidelines for the use of Variable Bit Rate Audio with Secure RTP as informational (or possibly BCP)

We took a brief show of hands in the meeting room in Beijing to see that there was a community that would support the work, and to see if others thought that these either should not be performed or interfered with the existing workload. So if you wish to add your opinion to these please:

For each of the above proposals indicate to the chairs at [email-masked] (or to the list if you wish) if:

A)	you are prepared to support the work in AVT by reviews, comments proposed text or other appropriate means.

B)	you believe creation of this milestone is either inappropriate or will have a detrimental impact on resources available to other work in AVT.

If you already represented your view in the meeting room in Beijing (or by Jabber), or do not wish to indicate eother A) or B), you do not need to respond.

There are candidate author drafts for all of these milestones if you wish to review the potential work.

https://datatracker.ietf.org/doc/draft-ivov-avt-slic/
https://datatracker.ietf.org/doc/draft-lennox-avt-rtp-audio-level-exthdr/
https://datatracker.ietf.org/doc/draft-wu-avt-retransmission-supression-rtp/
https://datatracker.ietf.org/doc/draft-perkins-avt-srtp-vbr-audio/

regards

Keith

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 12 Nov 2010 01:51:35 +0100

I neglected to put a deadline on this.

Please respond to the chairs by close of business on Friday November 19th.

regards

Keith 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of DRAGE, Keith (Keith)
> Sent: Thursday, November 11, 2010 11:48 PM
> To: [email-masked]
> Subject: [AVT] Adoption of new milestones
> 
> (As AVT WG cochair)
> 
> We are looking to see if we should adopt a number of new 
> milestones in AVT. This is the adoption of the milestone, not 
> the selection and adoption of an particular draft to fulfil 
> that milestone (that comes later). 
> 
> -	Guidelines for the use of Variable Bit Rate Audio with 
> Secure RTP as informational (or possibly BCP)
> 
> We took a brief show of hands in the meeting room in Beijing 
> to see that there was a community that would support the 
> work, and to see if others thought that these either should 
> not be performed or interfered with the existing workload. So 
> if you wish to add your opinion to these please:
> 
> For each of the above proposals indicate to the chairs at 
> [email-masked] (or to the list if you wish) if:
> 
> A)	you are prepared to support the work in AVT by reviews, 
> comments proposed text or other appropriate means.
> 
> B)	you believe creation of this milestone is either 
> inappropriate or will have a detrimental impact on resources 
> available to other work in AVT.
> 
> If you already represented your view in the meeting room in 
> Beijing (or by Jabber), or do not wish to indicate eother A) 
> or B), you do not need to respond.
> 
> There are candidate author drafts for all of these milestones 
> if you wish to review the potential work.
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Tue, 16 Nov 2010 12:02:29 +0100

Hi,

On the item: "RTCP indication for retransmission suppression as proposed standard"

As expressed in various emails I am not convinced there is need for such a new draft/mile stone, as RFC 4585 has addressed the problem IMO. The authors should first clarify what use cases are addressed that are not covered by RFC 4585, and linked to that, why a new RTCP message needs to be defined.  

(Note that the name is wrong: it is actually about feedback suppression, not retransmission suppression!!)

Tom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
Sent: vrijdag 12 november 2010 0:48
To: [email-masked]
Subject: [AVT] Adoption of new milestones

(As AVT WG cochair)

regards

Keith

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 16 Nov 2010 15:22:08 +0100

(As WG co-chair)

> > Secure RTP as informational (or possibly BCP) 

I have received no comments to these being adopted beyond those seen in the face-to-face meeting in Beijing, and Roni and I will seek to set these milestones with the Area Director. 

If the authors of the related drafts have views on how long these should take for WG review, closing of open issues and WGLC, then please inform the WG chairs (be pessimistic rather than optimistic).

> > -	RTCP indication for retransmission suppression as 

there is discussion still ongoing on the list. I propose to let that discussion continue for a few days before the chairs come to a conclusion on the result.

regards

Keith

> Sent: Friday, November 12, 2010 12:52 AM
> To: [email-masked]
> Subject: Re: [AVT] Adoption of new milestones
> 
> milestones in 
> > AVT. This is the adoption of the milestone, not the selection and 
> > adoption of an particular draft to fulfil that milestone 
> (that comes 
> > later).
> > 
> > We took a brief show of hands in the meeting room in Beijing to see 
> > that there was a community that would support the work, and 
> to see if 
> > others thought that these either should not be performed or 
> interfered 
> > with the existing workload. So if you wish to add your opinion to 
> > these please:
> > 
> > inappropriate or will have a detrimental impact on 
> resources available 
> > to other work in AVT.
> > 
> > If you already represented your view in the meeting room in Beijing 
> > (or by Jabber), or do not wish to indicate eother A) or B), 
> you do not 
> > need to respond.
> > 
> > There are candidate author drafts for all of these 
> milestones if you 
> > wish to review the potential work.
> >

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 16 Nov 2010 15:25:05 +0100

(As WG chair)

I realise I've confused my deadlines here, and prempted the deadline I set, so you have a few more days to respond on all of these. 

Keith

> From: DRAGE, Keith (Keith) 
> Sent: Tuesday, November 16, 2010 2:22 PM
> To: DRAGE, Keith (Keith); [email-masked]
> Subject: RE: Adoption of new milestones
> 
> (As WG co-chair)
> 
> For:
> 
> I have received no comments to these being adopted beyond 
> those seen in the face-to-face meeting in Beijing, and Roni 
> and I will seek to set these milestones with the Area Director. 
> 
> If the authors of the related drafts have views on how long 
> these should take for WG review, closing of open issues and 
> WGLC, then please inform the WG chairs (be pessimistic rather 
> than optimistic).
> 
> For:
> 
> there is discussion still ongoing on the list. I propose to 
> let that discussion continue for a few days before the chairs 
> come to a conclusion on the result.
> 
> regards
> 
> Keith
> 
> > Please respond to the chairs by close of business on Friday 
> November 
> > 19th.
> > 
> > regards
> > 
> > Keith
> >

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 17 Nov 2010 10:53:25 +0700

Van Caenegem, Tom (Tom) [mailto://[email-masked]]
writes:

> As expressed in various emails I am not convinced there is need for such
> a new draft/mile stone, as RFC 4585 has addressed the problem IMO. The
> authors should first clarify what use cases are addressed that are not
> covered by RFC 4585, and linked to that, why a new RTCP message needs to
> be defined.

I believe that Colin has already addressed this issue, repeatedly.

> not retransmission suppression!!)

Yes, so I would support the adoption of the draft with a name change (maybe
draft-ietf-avt-rtcp-feedback-suppression-00?).

~gwz

You don't get to choose how you're going to die.  Or when.  You can only
decide how you're going to live.  Now.
 -- Joan Baez

---

From: Qin Wu <[email-masked]>
Date: Wed, 17 Nov 2010 13:50:56 +0800

Hi,
----- Original Message ----- 
From: "DRAGE, Keith (Keith)" <[email-masked]>
To: <[email-masked]>
Sent: Friday, November 12, 2010 7:47 AM
Subject: [AVT] Adoption of new milestones

> - RTP Header extension for client to mixer audio level indication as proposed standard

[Qin]: This two works are interesting, I would like to see them go ahead.

> - RTCP indication for retransmission suppression as proposed standard

[Qin]:I believe this work can be useful for the middlebox or media source to refrain feedback implosion(e.g., retransmission request storm).
It provides the recievers with clear semantics for suppression indication and can trigger the receiver to employ the  suppression algorithm specifed in RFC4585
to alleviate the feedback implosion. 

So  I support to adopt this milestone and would like to see move this work forward.

> - Guidelines for the use of Variable Bit Rate Audio with Secure RTP as informational (or possibly BCP)

[Qin]: I think this work is useful to mitigate the risk of using VBR audio with SRTP and would like to see this work move ahead. Also I am willing to provide reivew on this work.

---

From: Qin Wu <[email-masked]>
Date: Wed, 17 Nov 2010 14:14:21 +0800

Hi,
Feedback Suppression algorithm specified in RFC4585 is just *receiver algorithm* about how the receiver tunes the 
timing of sending Feedback message to the sender to avoid currenncy of large number of  feedback *in the same group*.
the media source or middlebox can be in the different group as receivers. This alogorithm applies for all the existing feedback message
and new feedback message.

draft-wu-avt-retransmission-suppression-rtp  focuses on specifying *mechanism* on how the sender or 
server(e.g., media source or middlebox)  informs  the receiver that packet loss is detected and sending feedback for 
packet loss should be held on right now in case of packet loss occuring close to the media sender or at the upstream of middlebox. 
The mechanism needs *RTCP extension* and can be used to avoid large number of feedback addressed to *the same media source or middlebox at the upstream*.

The suppression indication mechanism specified in draft-wu-avt-retransmission-suppression-rtp does not need to rely on any other reciever reporting packet loss event.
the media souce or middlebox can detect pakcet loss by themselves and create new suppression messsages to the receivers.

Therefore RFC4585 and draft-wu-avt-retransmission-suppression-rtp address the different aspects or use cases of the problem.
Also Feedback Suppression Indication mechanism can be used with Feedback Suppression algorithm specified in RFC4585.

As regarding why the new RTCP message needs to be defined, there are many direct or indirect reasons based on my understanding and many discussion in the previous two IETF meeting:

1. RFC4585 only solves how to reduce the RTCP traffic storm within the same group by using reciever suppression algorithm, 
   however how to reduce upstream RTCP traffic beyond the group of recievers  when large number of feedbacks for lost packet  
   are addressed to the same media source  and middlebox is not covered.

2. The mechanism specified in draft-wu-avt-retransmission-suppression does not need to rely on 
    any NACK from any other reciever to detect the packet loss, the middlebox or media source can detect packet
    loss by themselves  and inform the receiver the lost event as early as possible by sending the RTCP message to downstream.

3. Relying on NACK from any dedicated reciever to report loss packet may slow down suppression operation by introducing extra roundtrip 
    between dedicated reciever and middlebox comparing with using middlebox to inform the receiver about suppression indication. Also 
   NACK lack scemantics for supppression indication to the receiver.

4. NACK is sent from AVPF receiver to the upstream AVPF sender, e.g., in RAMS case, the RTP_Rx can issue retransmission requests via RTCP NACK
    messages sent as unicast feedback in the primary multicast RTP session to BRS for lost packet. in such case, RTP_Rx is reciever and BRS is Sender.
    however in many use cases of draft-wu-retransmission-suppression-rtp or RTP topologies defined in RFC5117, we also need one message sent from 
   upstream sender to the downstream reciever  which can not be satisfied using NACK. Therefore  rough consesus shows that it is better to define the 
   new suppression messsage which is created by media source or middlebox itself and sent  to the downstream receiver.

5. RFC4585 allows receiver receive and process different Feedback message including any new feedback message like the 
    new suppression message defined in draft-wu-avt-retransmission-suppression-rtp.

Hope this clarifies.

Regards!
-Qin

---

From: Colin Perkins <[email-masked]>
Date: Wed, 17 Nov 2010 09:43:37 +0000

On 17 Nov 2010, at 03:53, Glen Zorn wrote:
> Van Caenegem, Tom writes:
> 
> Yes, so I would support the adoption of the draft with a name change (maybe draft-ietf-avt-rtcp-feedback-suppression-00?).

I support this draft, and agree with the suggestion for the name change. I'll continue to provide feedback on the draft.

-- 
Colin Perkins
http://csperkins.org/

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Thu, 18 Nov 2010 15:33:03 +0100

Hi Qin,

A server/sender that by itself detects packet loss (on its uplink), functions as an RTP receiver and hence can itself send a NACK, to which the other RTP receivers then react according to RFC 4585. This is the major point of divergence with the views expressed in your draft. 

E.g. RFC 5760 states  (p13) :   "From an RTP perspective, the Distribution Source is an RTP receiver, generating its own Receiver Reports and sending them to the receiver group and to the Media Senders."

Also in RFC 5117 there is language that indicates a transport translator can act as a receiver (section 3.3): "A Translator normally does not use an SSRC of its own, and is not visible as an active participant in the session.  One exception can
   be conceived when a Translator acts as a quality monitor that sends
   RTCP reports and therefore is required to have an SSRC.  Another
   example is the case when a Translator is prepared to use RTCP
   feedback messages.  This may, for example, occur when it suffers
   packet loss of important video packets and wants to trigger repair by
   the media sender, by sending feedback messages.  To be able to do
   this it needs to have a unique SSRC."

So I do not agree when you say there is a "dedicated" receiver required and when you say there is additional RTT involved, when using NACKs as suppression indication.

I do not exactly get your point when you say " RFC4585 only solves how to reduce the RTCP traffic storm within the same group by using reciever suppression algorithm, however how to reduce upstream RTCP traffic beyond the group of recievers  when large number of feedbacks for lost packet are addressed to the same media source  and middlebox is not covered."

Can you elaborate on that, please?

Regards
Tom

-----Original Message-----
From: Qin Wu [mailto:[email-masked]] 
Sent: woensdag 17 november 2010 7:14
To: Van Caenegem, Tom (Tom); DRAGE, Keith (Keith); [email-masked]
Subject: Re: [AVT] Adoption of new milestones

Hi,
Feedback Suppression algorithm specified in RFC4585 is just *receiver algorithm* about how the receiver tunes the timing of sending Feedback message to the sender to avoid currenncy of large number of  feedback *in the same group*.
the media source or middlebox can be in the different group as receivers. This alogorithm applies for all the existing feedback message and new feedback message.

draft-wu-avt-retransmission-suppression-rtp  focuses on specifying *mechanism* on how the sender or server(e.g., media source or middlebox)  informs  the receiver that packet loss is detected and sending feedback for packet loss should be held on right now in case of packet loss occuring close to the media sender or at the upstream of middlebox. 
The mechanism needs *RTCP extension* and can be used to avoid large number of feedback addressed to *the same media source or middlebox at the upstream*.

Hope this clarifies.

Regards!
-Qin

---

From: Qin Wu <[email-masked]>
Date: Fri, 19 Nov 2010 11:28:35 +0800

Hi, Tom:
Thank you for feedback very early. :-)
I didn't say the sender/middlebox can not send feedback message to the upstream node like media source for some purpose,e.g., ask for retransmission of losted packet, but it is weird to ask the sender/middlebox send the same feedback message to upstream node and downstream receiver to ask for the lost packet at the same time . This cause scemantics confusion.

Feedback Indication message defined in draft-wu-avt-retransmission-suppression-rtp and receiver reports, Sender Report defined in RFC3550 and reciever summary  Information(RSI) packet defined in RFC5760 are all RTCP message. However Unlike receiver reports , and RSI packet, Feedback Indication message is one feedback message and more look like sender report. But it is confusing to mix RTCP AVPF transport layer Feedback messsage with Receiver report or any other kind of report.

As described in RFC4585
"
  Generic NACK feedback SHOULD NOT be used if the underlying transport
   protocol is capable of providing similar feedback information to *the
   sender* (as may be the case, e.g., with DCCP).

"
 In many cases NACK is sent from media receiver at the downstream side to the media sender at the upstream side. e.g., In RAMS case, NACK is sent from RTP_Rx to the RBS to ask for Retransmission of lost packet. However you can not expect the RBS to send the NACK to the RTP_Rx to ask for Retransmission of lost packet. becos the RTP_Rx is not sender from the RBS perspective. But if RBS ask for retransmission of lost packet from the media source, the RBS take the role of the receiver from the media source perspective. But It is confusing to look at RBS as Receiver from both Media source perspective and RTP_Rx perspective.
This had been discussed in the previous meeting and mailing list for many times. It is not just my personal view.
As for the other feedback message like Picture Loss Indication (PLI) and Slice Loss Indication (SLI), they are both sent from downstream decoder to the upstream encoder. But In the draft-wu-avt-retransmission-suppression-rtp,
we do need a RTCP Indication message sent from upstream sender to the downstream RTP_Rx. 

As for the additional RTT issues, this issues had been discussed very eraly, please look at the following link to this discussion:
http://www.ietf.org/mail-archive/web/avt/current/msg13299.html

As for the last point you mentioned, as I explained, RFC4585 just provide the receiver with one algorithm on how to schedule its own feedback when the receiver is the same group with other receivers. However when packet loss
happens close to media source, all the recievers may send feedback almost at the same time concurrently, it does not make sense to ask all the recievers listen on this problem when all the reciever have already sent the feedback message out.

You may also look at the figure 1 and section 5 of RFC5968, you can see Sender Report in the downsream direction and Receiver Report  in the upstream direction construct the complete Feedback Loop. 
But you can not expect to use one NACK message in both directions to construct the Feedback Loop.

Hope this clarifies.

Regards!
-Qin
----- Original Message ----- 
From: "Van Caenegem, Tom (Tom)" <[email-masked]>
To: "Qin Wu" <[email-masked]>; "DRAGE, Keith (Keith)" <[email-masked]>; <[email-masked]>
Sent: Thursday, November 18, 2010 10:33 PM
Subject: RE: [AVT] Adoption of new milestones

Hi Qin,

Regards
Tom

-----Original Message-----
From: Qin Wu [mailto:[email-masked]] 
Sent: woensdag 17 november 2010 7:14
To: Van Caenegem, Tom (Tom); DRAGE, Keith (Keith); [email-masked]
Subject: Re: [AVT] Adoption of new milestones

Hi,

Hope this clarifies.

Regards!
-Qin

---

From: Qin Wu <[email-masked]>
Date: Fri, 19 Nov 2010 12:22:43 +0800

Hi, Chairs:
Please note that  there were the same interests and supports to adopt the milestone on "RTCP
 indication for Feedback suppression" in the face to face meeting in Beijing as the other milestones you mentioned.
I remembered there are 7 people who vote to support this milestone.

We also have got lots of reviews and supports on the list in the last two IETF meetings. Special thanks to David R Oran
who put lots of effort to help on getting this work polished before IETF Beijing meeting. Also thank for all the other
experts review to move this work forward.

In response to chairs call for the timeframe of milestone at the end of deadline, I suggest the milestone on "RTCP
 indication for Feedback suppression" to go for WG last call for April 2011 (IETF80).

Many Thanks!

Regards!
-Qin

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Fri, 19 Nov 2010 11:32:05 +0100

Hi Qin,

See my comments below
(Tom)..
Regards.

-----Original Message-----
From: Qin Wu [mailto:[email-masked]]
Sent: vrijdag 19 november 2010 4:29
To: Van Caenegem, Tom (Tom); DRAGE, Keith (Keith); [email-masked]
Subject: Re: [AVT] Adoption of new milestones

Hi, Tom:

Tom: this is the definition of the NACK message in RFC 4585: "The Generic NACK is used to indicate the loss of one or more RTP packets".
So, if a entity declared itself to provide retransmissions, and it gets this NACK, it may send a corresponding retransmission as  response on receiving this NACK (RFC 4588). If an entity is "just" an RTP receiver for the considered SSRC and receives a NACK, it must act according to RFC 4585, which specifies how it should refrain from immediately sending a NACK, when it detected the same packet loss. There is no semantics confusion.

As described in RFC4585
"

Tom: not sure what your message is here.. DCCP combining with multicast looks problematic.

 In many cases NACK is sent from media receiver at the downstream side to the media sender at the upstream side. e.g., In RAMS case, NACK is sent from RTP_Rx to the RBS to ask for Retransmission of lost packet. However you can not expect the RBS to send the NACK to the RTP_Rx to ask for Retransmission of lost packet.

Tom: as defined in RFC 4585, and explained above, a NACK is NOT about asking retransmission, it is about packet loss reporting.

Tom: in the RAMS case, the BRS/FT will most likely be decoupled from the DS. If you want the BRS/FT to advertise the observed packet loss to the RTP receivers reporting to this FT, how will you get that message to the RTP receivers? This is one of the issues that need to be solved/defined, and I have not seen this addressed in the draft...

becos the RTP_Rx is not sender from the RBS perspective. But if RBS ask for retransmission of lost packet from the media source, the RBS take the role of the receiver from the media source perspective. But It is confusing to look at RBS as Receiver from both Media source perspective and RTP_Rx perspective.

Tom: I know all this. I responded on your assertion that if the middle box sends a NACK to indicate suppression indication -iso a dedicated RTCP message-, this has additional RTT delay. This is incorrect if the packet loss took place upstream of the middle box.

As for the last point you mentioned, as I explained, RFC4585 just provide the receiver with one algorithm on how to schedule its own feedback when the receiver is the same group with other receivers. However when packet loss happens close to media source, all the recievers may send feedback almost at the same time concurrently, it does not make sense to ask all the recievers listen on this problem when all the reciever have already sent the feedback message out.

Tom: I agree, and again,  having the middle box sending a NACK to all receivers iso of the suppression indication will result in the same behaviour at the receivers. Unless you want a receiver behaviour different from the one defined in RFC 4585.

Tom: do not agree: if a middelbox also acts as receiver in a multi party session, it sends its RTCP reports to all participants, resulting in FB suppression as per RFC 4585.

Hope this clarifies.

Tom: not really.....so where do we go from here? To me it would make sense to explain more in a generic way how feedback storms in multi-point RTP sessions (including SSM) can be prevented or mitigated  (see http://www.ietf.org/mail-archive/web/avt/current/msg13785.html ), see where it would make sense to have an explicit suppression indication rather than using NACK (or other FB message) for this, and -very important - also elaborate how the suppression indication/NACK is provided to the receivers (e.g. the RAMS topology). I suggest therefore to rename the draft as "feedback suppression in multi-point sessions", and address the items as per above.

Regards!
-Qin
----- Original Message -----
From: "Van Caenegem, Tom (Tom)" <[email-masked]>
To: "Qin Wu" <[email-masked]>; "DRAGE, Keith (Keith)" <[email-masked]>; <[email-masked]>
Sent: Thursday, November 18, 2010 10:33 PM
Subject: RE: [AVT] Adoption of new milestones

Hi Qin,

Regards
Tom

-----Original Message-----
From: Qin Wu [mailto:[email-masked]]
Sent: woensdag 17 november 2010 7:14
To: Van Caenegem, Tom (Tom); DRAGE, Keith (Keith); [email-masked]
Subject: Re: [AVT] Adoption of new milestones

Hi,

Hope this clarifies.

Regards!
-Qin

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sat, 20 Nov 2010 22:19:30 +0100

(As WG cochair)

For the question on adoption of milestones on:

In general the comments have been positive on adopting these and there was only one comment against "RTCP indication for retransmission suppression as proposed standard"

So we take this as consensus that the group is happy to work on these four deliverables.

What happens next:

1)	Roni and I will agree proposed dates next week and ask the AD to adopt the milestones.

If authors have not sent us a suggested milestone date and wish to do so, then that option is still open. In any case Roni and I will use our judgement based on the load on the working group in making a proposal.

2)	Various comments have been received as part of this process on the various related author drafts. Authors please feel free to update your documents prior to us asking to adopt drafts for these milestones. If you consider a comment requires further discussion, please feel free to open a specific thread on the avt list concentrating on that comment raised.

3)	If any AVT participant feels that an alternative proposal is worthwhile of consideration for these milestones, please feel free to submit your own author draft to cover any of these milestones.

4)	Once the milestones are set (probably in about two or so weeks), we will be looking to adopt baseline text / drafts as the working group draft to progress. So do try and complete 2) and 3) above in that timescale. If anyone believes more time is needed, then please send mail.

regards

Keith

> November 19th.