Subject: [MMUSIC] WGLC on draft-ietf-mmusic-t140-usage-data-channel-06

From: Bo Burman <[email-masked]>
Date: Wed, 2 Oct 2019 13:25:13 +0000

Greetings MMUSIC ,

This is to announce a 2 week WGLC on the draft:

    https://www.ietf.org/id/draft-ietf-mmusic-t140-usage-data-channel-06.txt

as Proposed Standard. Please review and provide any comments you may have on the document by Wednesday, October 16, 2019. Comments should be sent to the document authors and the MMUSIC WG list. If you review the document but do not have any comments, please send a note to that effect as well.

Thanks,

/Bo

(MMUSIC co-chair)

---

From: "Roni Even (A)" <[email-masked]>
Date: Thu, 3 Oct 2019 09:27:19 +0000

Hi,
I reviewed the draft and have no comments.

I am wondering what does it mean if the there is no language specified in the offer?

One nit: in section 4.2.3.1.1 "the offerer can start to send T.140 data as soon" change to "the offerer can start sending T.140 data as soon"

Roni Even

From: mmusic [mailto:[email-masked]] On Behalf Of Bo Burman
Sent: Wednesday, October 02, 2019 4:25 PM
To: mmusic ([email-masked])
Subject: [MMUSIC] WGLC on draft-ietf-mmusic-t140-usage-data-channel-06

Greetings MMUSIC ,

Thanks,

/Bo
(MMUSIC co-chair)

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 3 Oct 2019 10:00:07 +0000

Hi,

I have reviewed draft-ietf-mmusic-t140-usage-data-channel-06<https://www.ietf.org/id/draft-ietf-mmusic-t140-usage-data-channel-06.txt> and find it to be in good shape, important and sufficient for its purpose. I see also that further separate work is desirable for the multi-party considerations and the gateway considerations.

I found some places where mainly editorial improvements can be made:

1. In 4.1, misspelling. "descripton" sb "description"

2. In 4.1 Note, misspelling "negotied" sb "negotiated"

3. In 1., line 4  the last informational reference in the paragraph should be to RFC 3550 instead of RFC 4103

4. In 3, delete "using the RTP timestamp". It is usually the sequence number that helps finding where data is missing.

5. In 4.2, first line: "an SDP 'dcsa' attribute" s.b. "one or more SDP 'dcsa' attributes"

6. At the end of 4.2, add "section 6.7" because it is hard to find in sdpneg where it is specified how to handle unknown attributes (and the wording in 6.7 is confusing, but that is another matter)

7. In 4.2.3 delete the last sentence "An offerer and answerer MUST mark the direction of the text by sending a direction attribute inside 'dcsa' attribute." This is superfluous information, and it can be misunderstood that the direction attribute always must be explicitly provided. (another solution could be to improve the sentence by including when the direction must be included)

8. In 4.2.3.1.1 "both send or receive" s.b. "both send and receive"

9. In 4.2.3.1.2 all "MUST" sb changed to "SHOULD", because the last paragraph of 4.2.3.1.1 says that the answerer might not support direction marking. It is then illogical to require that.

10. In 4.2.3.1.2 second paragraph. The wording about not indicating 'sendrecv' means implicit marking as sendrecv is a bit confusing and may cause implementers to believe that they must always provide explicit marking of direction. A remedy might be to swap order between the two sentences in the second paragraph and insert "(implicitly or explicitly)" after "sendrecv" to make the paragraph wording:

"If the answerer does not explicitly mark the data channel, a 'sendrecv' attribute inside a 'dcsa' attribute is implicitly applied. If the offerer marked the data channel as sendrecv (implicitly or explicitly), the answerer SHOULD mark the data channel as sendrecv(implicitly or explicitly), sendonly, recvonly or inactive with a 'sendrecv', 'sendonly', 'recvonly' respective 'inactive' attribute inside a 'dcsa' attribute. "

11. In 4.3 Examples, some values are unusual and should be selected to be more natural:
The stream-id in the offer is very often even because it is most often the same party who takes the initiative to the SCTP association who also sends the initial offer. Thus, change all stream-id in the examples from the odd 1 to e.g. the even 2

Use different udp port numbers in the m-lines in the offers and corrsponding answers.

Use different sctp port numbers in offers and corresponding answers.

12. In 5.2 Change the header to "5.2 Data Encoding, Sending and Receiving"
and insert last this important hint for interoperability.

"The T.140 coding details contain information on optional control codes intended for controlling the presentation that may not be supported by the presentation level of the receiving application. The receiving application MUST handle reception of such T.140 control codes properly (e.g. ignore them) even if their effect on presentation is not supported."

13. In 6. Gateway considerations:

At the end of bullet point 4 add "in reception"

14. In 6. Gateway considerations:
After bullet point 4, add one more bullet point:
"If the gateway detects that the T.140 data channel has failed and got torn down, once the data channel has been reestablished the gateway SHOULD insert the T.140 missing text marker [T140ad1]<https://tools.ietf.org/id/draft-ietf-mmusic-t140-usage-data-channel-06.html#T140ad1> in the data sent on the outgoing T.140 data channel if it detects or suspects that data sent or to be sent on the T.140 data channel was lost during the failure. Data that may have been correctly transmitted and received MUST not be repeated."

15. In 6. Gateway considerations:
In the last bullet point, change MUST to SHOULD, because we say above that some implementations may not support the direction attributes.

16. In 7 Update to RFC 8373
Reference for RFC 8373 is missing

17. In 11.2 Informational references:
Add reference to RFC 3550 as indicated in point 3 above.

I intend to provide these comments also as change proposals in GitHub.

Regards

Gunnar Hellström

Den 2019-10-02 kl. 15:25, skrev Bo Burman:
Greetings MMUSIC ,

Thanks,

/Bo
(MMUSIC co-chair)

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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 3 Oct 2019 11:08:21 +0000

Hi Gunnar,

Thank You for the review! Please see inline.

> I have reviewed draft-ietf-mmusic-t140-usage-data-channel-06 and find it to be in good shape, important and sufficient for its purpose. I see also that
> further separate work is desirable for the multi-party considerations and the gateway considerations.
>

Will be fixed.

>2. In 4.1 Note, misspelling "negotied" sb "negotiated"

Will be fixed.

>3. In 1., line 4  the last informational reference in the paragraph should be to RFC 3550 instead of RFC 4103

Will be fixed.

> 4. In 3, delete "using the RTP timestamp". It is usually the sequence number that helps finding where data is missing.

The sequence number is used to detect missing data, but the timestamp is used for data redundancy.

   "The RTP header is followed by one or more redundant data block
   headers: one for each redundant data block to be included.  Each of
   these headers provides the timestamp offset and length of the
   corresponding data block,"  (RFC 4103, Section 4.1)

>5. In 4.2, first line: "an SDP 'dcsa' attribute" s.b. "one or more SDP 'dcsa' attributes"

Will be fixed.

>6. At the end of 4.2, add "section 6.7" because it is hard to find in sdpneg where it is specified how to handle unknown attributes (and the wording in 6.7 is confusing, but that is another matter)

Will be fixed.

> 7. In 4.2.3 delete the last sentence "An offerer and answerer MUST mark the direction of the text by sending a direction attribute inside 'dcsa' attribute." 
> This is superfluous information, and it can be misunderstood that the direction attribute always must be explicitly provided. (another solution could be to
> improve the sentence by including when the direction must be included)

I suggest to delete the last sentence.

> 8. In 4.2.3.1.1 "both send or receive" s.b. "both send and receive"

Will be fixed.

> 9. In 4.2.3.1.2 all "MUST" sb changed to "SHOULD", because the last paragraph of 4.2.3.1.1 says that the answerer might not support
> direction marking. It is then illogical to require that.  
>
> 10. In 4.2.3.1.2 second paragraph. The wording about not indicating 'sendrecv' means implicit marking as sendrecv is a bit confusing and may
> cause implementers to believe that they must always provide explicit marking of direction. A remedy might be to swap order between the two
> sentences in the second paragraph and insert "(implicitly or explicitly)" after "sendrecv" to make the paragraph wording:
>"If the answerer does not explicitly mark the data channel, a 'sendrecv' attribute inside a 'dcsa' attribute is implicitly applied. If the offerer
> marked the data channel as sendrecv (implicitly or explicitly), the answerer SHOULD mark the data channel as sendrecv(implicitly or explicitly),
> sendonly, recvonly or inactive with a 'sendrecv', 'sendonly', 'recvonly' respective 'inactive' attribute inside a 'dcsa' attribute. "

I don't like the SHOULD. We define the procedures for an answerer that do support the procedures. 

The last paragraph of Section 4.2.3.1.1 already points out that the answerer may not support setting the direction attribute, and how the offerer handles it.

Other than that, I am fine with your suggestion to change the ordering.

Or, we could make it even shorter:

   "If the offerer marked the data channel as sendrecv (implicitly or
     explicitly), the answerer MUST mark the data channel as sendrecv
     sendrecv (implicitly or explicitly), sendonly, recvonly or inactive with
     a 'sendrecv', 'sendonly', 'recvonly' respective 'inactive' attribute inside
     a 'dcsa' attribute."

> The stream-id in the offer is very often even because it is most often the same party who takes the initiative to the SCTP association
> who also sends the initial offer. Thus, change all stream-id in the examples from the odd 1 to e.g. the even 2

Will fix.

> Use different udp port numbers in the m-lines in the offers and corrsponding answers.

Will fix.

> Use different sctp port numbers in offers and corresponding answers.

Will fix.

> "The T.140 coding details contain information on optional control codes intended for controlling the
> presentation that may not be supported by the presentation level of the receiving application. The
> receiving application MUST handle reception of such T.140 control codes properly (e.g. ignore them)
> even if their effect on presentation is not supported." 

That is not data channel specific, is it? I assume it is already part of T.140, so we shall not specify new MUST requirements.

With that, I suggest to not change the title.

> At the end of bullet point 4 add "in reception"

I think "was lost in reception" sounds strange.  What about "was lost due to the data channel failure"?

> "If the gateway detects that the T.140 data channel has failed and got torn down, once the data channel has been reestablished the
> gateway SHOULD insert the T.140 missing text marker [T140ad1] in the data sent on the outgoing T.140 data channel if it detects or
> suspects that data sent or to be sent on the T.140 data channel was lost during the failure. Data that may have been correctly
> transmitted and received MUST not be repeated."

I don't think we need the last sentence, because it is confusing. It is enough to say that the procedure is done if the gateway detects or suspects that data was lost.

>the direction attributes.

We define the procedures for implementations that are compliant with the spec, and for such implementations it is a MUST.

We can have text about implementations that don't support the procedures (as we have in section 4.2.3.1.1., when the answerer does not support the direction attributes), and how it impacts things, but we shall not modify the normative procedures because of that. 

>Reference for RFC 8373 is missing

Will fix.

>Add reference to RFC 3550 as indicated in point 3 above.

Will fix.

> I intend to provide these comments also as change proposals in GitHub.

Ok.

Regards,

Christer

    https://protect2.fireeye.com/url?k=806502d9-dcecd8e4-80654242-0cc47ad93c0c-e10d1004cdda139e&q=1&u=https://www.ietf.org/id/draft-ietf-mmusic-t140-usage-data-channel-06.txt 

Thanks,

/Bo
(MMUSIC co-chair) 

_______________________________________________
mmusic mailing list
mailto:[email-masked]
https://protect2.fireeye.com/url?k=a6662b9d-faeff1a0-a6666b06-0cc47ad93c0c-f61b6b0757d55756&q=1&u=https://www.ietf.org/mailman/listinfo/mmusic

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 3 Oct 2019 12:10:33 +0000

Hi Christer, please see responses inline,

>     corresponding data block,"  (RFC 4103, Section 4.1)
{GH] Well, that is the coding of the redundancy data block, but not how 
loss is detected. I do not know any implementation that bothers about 
details in the RTP timestamp for detecting loss. Instead, the sequence 
numbers of the redundant parts can be evaluated by subtraction from the 
current RTP sequence number and then it is easy to detect if some data 
needs to be recovered from the redundant parts or if there is a 
irrecoverable gap in received sequence numbers. So, I sustain my 
proposal to delete "using the RTP timestamp".
> I suggest to delete the last sentence.
[GH] good
>       a 'sendrecv', 'sendonly', 'recvonly' respective 'inactive' attribute inside
[GH] accepted, ( but you have double sendrcv on lines 2-3 in your 
proposal above)
> With that, I suggest to not change the title.
[GH] Right, but it is an important reminder for interoperability between 
implementations. So, make it a NOTE instead and change the MUST to 
something suitable (needs to ?).
> I think "was lost in reception" sounds strange.  What about "was lost due to the data channel failure"?
[GH] I wanted to point out in what direction it was lost. In T.140 data 
channels, the sender has in fact better opportunity than the receiver to 
detect if something was lost. Bullet point 4 was intended to tell about 
data received on the T.140 data channel to be sent on the RTP stream. I 
want to insert a new bullet point (see 14) for when the gateway detects 
loss in sending in the T.140 data channel. Therefore it should be clear 
that bullet point 4 is for the reception case. What about "was lost when 
receiving from the T.140 data channel due to the data channel failure" ?
> I don't think we need the last sentence, because it is confusing. It is enough to say that the procedure is done if the gateway detects or suspects that data was lost.
[GH] Accepted
> We can have text about implementations that don't support the procedures (as we have in section 4.2.3.1.1., when the answerer does not support the direction attributes), and how it impacts things,…
[GH]Accepted. The language you ask for is kind of already there, so I do 
not require anything more here.

Regards

Gunnar

-- 

+ + + + + + + + + + + + + +

Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 3 Oct 2019 13:40:41 +0000

I have now created GitHub pull requests for all accepted or still 
discussed points from the 17 point list below.

Regards

Gunnar

Den 2019-10-03 kl. 14:10, skrev Gunnar Hellström:
>>> I have reviewed draft-ietf-mmusic-t140-usage-data-channel-06 and 
>>> find it to be in good shape, important and sufficient for its 
>>> purpose. I see also that
>>> further separate work is desirable for the multi-party 
>>> considerations and the gateway considerations.
>>>
>>> 3. In 1., line 4  the last informational reference in the paragraph 
>>> should be to RFC 3550 instead of RFC 4103
>> Will be fixed.
>>
>>> 4. In 3, delete "using the RTP timestamp". It is usually the 
>>> sequence number that helps finding where data is missing.
> {GH] Well, that is the coding of the redundancy data block, but not 
> how loss is detected. I do not know any implementation that bothers 
> about details in the RTP timestamp for detecting loss. Instead, the 
> sequence numbers of the redundant parts can be evaluated by 
> subtraction from the current RTP sequence number and then it is easy 
> to detect if some data needs to be recovered from the redundant parts 
> or if there is a irrecoverable gap in received sequence numbers. So, I 
> sustain my proposal to delete "using the RTP timestamp".
>>> 6. At the end of 4.2, add "section 6.7" because it is hard to find 
>>> in sdpneg where it is specified how to handle unknown attributes 
>>> (and the wording in 6.7 is confusing, but that is another matter)
>> Will be fixed.
>>
>>> 7. In 4.2.3 delete the last sentence "An offerer and answerer MUST 
>>> mark the direction of the text by sending a direction attribute 
>>> inside 'dcsa' attribute."
>>> This is superfluous information, and it can be misunderstood that 
>>> the direction attribute always must be explicitly provided. (another 
>>> solution could be to
>>> 9. In 4.2.3.1.2 all "MUST" sb changed to "SHOULD", because the last 
>>> paragraph of 4.2.3.1.1 says that the answerer might not support
>>> 10. In 4.2.3.1.2 second paragraph. The wording about not indicating 
>>> 'sendrecv' means implicit marking as sendrecv is a bit confusing and 
>>> may
>>> cause implementers to believe that they must always provide explicit 
>>> marking of direction. A remedy might be to swap order between the two
>>> sentences in the second paragraph and insert "(implicitly or 
>>> explicitly)" after "sendrecv" to make the paragraph wording:
>>> "If the answerer does not explicitly mark the data channel, a 
>>> 'sendrecv' attribute inside a 'dcsa' attribute is implicitly 
>>> applied. If the offerer
>>> marked the data channel as sendrecv (implicitly or explicitly), the 
>>> answerer SHOULD mark the data channel as sendrecv(implicitly or 
>>> explicitly),
>>> sendonly, recvonly or inactive with a 'sendrecv', 'sendonly', 
>>> 'recvonly' respective 'inactive' attribute inside a 'dcsa' attribute. "
>> The last paragraph of Section 4.2.3.1.1 already points out that the 
>> answerer may not support setting the direction attribute, and how the 
>> offerer handles it.
>>
>>> The stream-id in the offer is very often even because it is most 
>>> often the same party who takes the initiative to the SCTP association
>>> who also sends the initial offer. Thus, change all stream-id in the 
>>> examples from the odd 1 to e.g. the even 2
>> Will fix.
>>
>> That is not data channel specific, is it? I assume it is already part 
>> of T.140, so we shall not specify new MUST requirements.
>>
> [GH] Right, but it is an important reminder for interoperability 
> between implementations. So, make it a NOTE instead and change the 
> MUST to something suitable (needs to ?).
> [GH] I wanted to point out in what direction it was lost. In T.140 
> data channels, the sender has in fact better opportunity than the 
> receiver to detect if something was lost. Bullet point 4 was intended 
> to tell about data received on the T.140 data channel to be sent on 
> the RTP stream. I want to insert a new bullet point (see 14) for when 
> the gateway detects loss in sending in the T.140 data channel. 
> Therefore it should be clear that bullet point 4 is for the reception 
> case. What about "was lost when receiving from the T.140 data channel 
> due to the data channel failure" ?
>>
>>> "If the gateway detects that the T.140 data channel has failed and 
>>> got torn down, once the data channel has been reestablished the
>>> gateway SHOULD insert the T.140 missing text marker [T140ad1] in the 
>>> data sent on the outgoing T.140 data channel if it detects or
>>> suspects that data sent or to be sent on the T.140 data channel was 
>>> lost during the failure. Data that may have been correctly
>> I don't think we need the last sentence, because it is confusing. It 
>> is enough to say that the procedure is done if the gateway detects or 
>> suspects that data was lost.
> [GH] Accepted
>>
>>> In the last bullet point, change MUST to SHOULD, because we say 
>>> above that some implementations may not support
>>> the direction attributes.
>> We define the procedures for implementations that are compliant with 
>> the spec, and for such implementations it is a MUST.
>>
>> We can have text about implementations that don't support the 
>> procedures (as we have in section 4.2.3.1.1., when the answerer does 
>> not support the direction attributes), and how it impacts things, but 
>> we shall not modify the normative procedures because of that.
> [GH]Accepted. The language you ask for is kind of already there, so I 
> do not require anything more here.
>>
>> as Proposed Standard. Please review and provide any comments you may 
>> have on the document by Wednesday, October 16, 2019. Comments should 
>> be sent to the document authors and the MMUSIC WG list. If you review 
>> the document but do not have any comments, please send a note to that 
>> effect as well.
>>
>> Thanks,
>>
>> /Bo
>> (MMUSIC co-chair)
>>
>>
-- 

Gunnar Hellström
Omnitor

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 3 Oct 2019 13:42:29 +0000

Hi Gunnar,

Please see inline.

...

    > loss is detected.

The beginning of the sentence says:

   "Instead, when RTP based transport is used, the RTP sequence number is used
    to detect packet loss and out-of-order packets"

    > I do not know any implementation that bothers about 
    > details in the RTP timestamp for detecting loss. 

    The text doesn't say that :)
 
...  

    Will be fixed.

...

    > something suitable (needs to ?).

What about?

   "NOTE: The T.140 encoding might also contain control codes intended for controlling the presentation
   of the real-time text. As defined in [T140], a T.140 endpoint is required to ignore received control codes
   that it does not support."

...

    > receiving from the T.140 data channel due to the data channel failure" ?
    
    What about?

    "that data sent by the T.140 data channel endpoint has been lost."

Regards,

Christer

    -- 

    Gunnar Hellström
    Omnitor

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 3 Oct 2019 18:43:46 +0000

Hi,

>      The text doesn't say that :)
[GH] But it also does not say how you can use the timestamp to detect 
loss and recover data from redundancy. RFC 4103 is using the redundancy 
mechanism in RFC 2198 originally used for audio redundancy. Maybe the 
timestamp is of more value there, when playing out audio is more 
time-critical than real-time text. The text you cited in RFC 4103 only 
tells how to code the redundancy block, not how to use the info for 
recovery. What we have in the t.140 data channel draft is sufficient 
without mentioning the timestamp in RFC 4103. Can we delete the 
discussed phrase?
> [GH] Yes, accepted.

[GH] I do not see why you do not like to mention reception here, so that 
it is clear in which direction there may have been a loss.

But your proposal may perhaps work if we clearly indicate the roles by 
inserting "remote" like this:

     "that data sent by the remote T.140 data channel endpoint has been lost."

because the gateway is also a kind of endpoint.

Regards
Gunnar

-- 

Gunnar Hellström
Omnitor

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 3 Oct 2019 21:12:13 +0000

Hi Gunnar,

> [GH] But it also does not say how you can use the timestamp to detect loss and recover data from redundancy.

It says that you can use the sequence number to detect loss.

> RFC 4103 is using the redundancy mechanism in RFC 2198 originally used for audio redundancy. Maybe the
> timestamp is of more value there, when playing out audio is more time-critical than real-time text. The text 
> you cited in RFC 4103 only tells how to code the redundancy block, not how to use the info for recovery. 
> What we have in the t.140 data channel draft is sufficient without mentioning the timestamp in RFC 4103. 
> Can we delete the discussed phrase?

I was asked to add a note that describes why we are using reliable and in-ordered transmission on the data channel, and why we can't use the
loss detection and redundancy encoding mechanisms defined for RTP in RFC 4103.

Also, the note does not talk about how redundancy blocks are encoded, it only says that there is a redundancy mechanism based on the usage of the RTP timestamp.

But, if you don't want to talk about the "RTP timestamp", perhaps we could talk about "redundancy being provided using a mechanism based on duplicating T140blocks".

...

> [GH] I do not see why you do not like to mention reception here, so that it is clear in which direction there may have been a loss.

I think talking about reception of something that was loss sounds strange. It is was lost, it wasn't received.

>But your proposal may perhaps work if we clearly indicate the roles by inserting "remote" like this:
>

I agree. We can do that.

Regards,

Christer

-- 

Gunnar Hellström
Omnitor

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 4 Oct 2019 07:44:21 +0000

Hi Gunnar,

I just approved the pull request regarding the "RTP timestamp". I had misunderstood, and thought you wanted to remove the whole sentence regarding redundancy, but I noted that you only removed the "RTP timestamp" part. I am ok with that.

Sorry for the confusion.

Regards,

Christer

...

On 04/10/2019, 0.12, "mmusic on behalf of Christer Holmberg" <[email-masked] on behalf of christer.holmberg=[email-masked]> wrote:

    Hi Gunnar,

    

    
    
    ...

    
    
    I agree. We can do that.
    
    Regards,
    
    Christer

    -- 

    Gunnar Hellström
    Omnitor
    
    _______________________________________________
    mmusic mailing list
    [email-masked]
    https://protect2.fireeye.com/url?k=b4182612-e891fc2f-b4186689-0cc47ad93c0c-d434da3bb25e359d&q=1&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmmusic

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 4 Oct 2019 14:26:05 +0000

> I just approved the pull request regarding the "RTP timestamp". I had misunderstood, and thought you wanted to remove the whole sentence regarding redundancy, but I noted that you only removed the…

Good. Agreed.

Gunnar

-- 

Gunnar Hellström
Omnitor

---

From: Bo Burman <[email-masked]>
Date: Fri, 18 Oct 2019 10:41:03 +0000

The 2-week WGLC is now concluded and a new version (-07) was submitted that
should address WGLC comments.

To WGLC commenters; please confirm that -07 addresses all of your concerns.

The changes between -06 and -07 can be seen here:

https://www.ietf.org/rfcdiff?url1=draft-ietf-mmusic-t140-usage-data-channel-
06
<https://www.ietf.org/rfcdiff?url1=draft-ietf-mmusic-t140-usage-data-channel
-06&url2=draft-ietf-mmusic-t140-usage-data-channel-07>
&url2=draft-ietf-mmusic-t140-usage-data-channel-07 

After receiving that confirmation, there doesn't seem to be any more issues
and writeup could start in preparation for publication.

Thanks,

/Bo

From: mmusic <[email-masked]> On Behalf Of Bo Burman
Sent: den 2 oktober 2019 15:25
To: mmusic ([email-masked]) <[email-masked]>
Subject: [MMUSIC] WGLC on draft-ietf-mmusic-t140-usage-data-channel-06

Greetings MMUSIC ,

as Proposed Standard. Please review and provide any comments you may have on
the document by Wednesday, October 16, 2019. Comments should be sent to the
document authors and the MMUSIC WG list. If you review the document but do
not have any comments, please send a note to that effect as well. 

Thanks,

/Bo

(MMUSIC co-chair)

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 20 Oct 2019 07:10:44 +0000

I confirm that version -07 adresses my concerns and is in good shape.

Thanks,

Gunnar Hellström

Den 2019-10-18 kl. 12:41, skrev Bo Burman:
The 2-week WGLC is now concluded and a new version (-07) was submitted that should address WGLC comments.

To WGLC commenters; please confirm that -07 addresses all of your concerns.
The changes between -06 and -07 can be seen here:
https://www.ietf.org/rfcdiff?url1=draft-ietf-mmusic-t140-usage-data-channel-06&url2=draft-ietf-mmusic-t140-usage-data-channel-07

After receiving that confirmation, there doesn’t seem to be any more issues and writeup could start in preparation for publication.

Thanks,

/Bo

From: mmusic <[email-masked]><mailto:[email-masked]> On Behalf Of Bo Burman
Sent: den 2 oktober 2019 15:25
To: mmusic ([email-masked]<mailto:[email-masked]>) <[email-masked]><mailto:[email-masked]>
Subject: [MMUSIC] WGLC on draft-ietf-mmusic-t140-usage-data-channel-06

Greetings MMUSIC ,

Thanks,

/Bo
(MMUSIC co-chair)

--