Subject: Re: [MMUSIC] 1-week WGLC on Section 7.6 (3PCC Considerations) in draft-ietf-mmusic-rfc8843bis-06

From: Christer Holmberg <[email-masked]>
Date: Wed, 1 Dec 2021 13:46:28 +0000

Roman/Justin, can you live with the suggestion based on Paul's comment, i.e., replace:

"Therefore, the  3PCC  controller SHOULD rewrite the subsequent BUNDLE Offer into a valid 
  initial BUNDLE Offer, following the procedures in Section 7.2, before it 
  forwards the BUNDLE Offer to a UA.  In the rewritten BUNDLE Offer the 
  3PCC controller will set the port value to zero (and include an SDP 
  'bundle-only' attribute) for each "m=" section within the BUNDLE group, 
  excluding the offerer-tagged "m=" section."

...with:

"Therefore, the 3PCC controller SHOULD take actions to mitigate this 
  problem, e.g., by rewriting the subsequent BUNDLE offer into a valid 
  initial BUNDLE offer (Section 7.2), before it forwards the BUNDLE 
  offer to a UA."

If not, please go into compromise mode and try to suggest something that would make anyone happy. I really don't want the work to get delayed because of this.

The IMPORTANT thing is to point out the PROBLEM - one endpoint sends a subsequent offer, and another endpoints expects an initial offer -and to give an EXAMPLE on how it CAN be solved. It's fine if someone wants to solve the problem in some other way, as long as it works...

Regards,

Christer

-----Original Message-----
From: mmusic <[email-masked]> On Behalf Of Paul Kyzivat
Sent: tiistai 30. marraskuuta 2021 18.24
To: [email-masked]
Subject: Re: [MMUSIC] 1-week WGLC on Section 7.6 (3PCC Considerations) in draft-ietf-mmusic-rfc8843bis-06

Christer,

On 11/29/21 2:00 PM, Christer Holmberg wrote:
> Hi Paul,
> 
> Since the issue is introduced by BUNDLE, I think we should say more 
> than simply "the 3PCC has to do something".
> 
> I am fine to change the current procedure from a SHOULD to an example, 
> but I do think we should include some guidance.
> 
> For example:
> 
> "Therefore, the 3PCC controller needs to take actions to mitigate this 
> problem, e.g., by rewriting the subsequent BUNDLE offer into a valid 
> initial BUNDLE offer (Section 7.2), before it forwards the BUNDLE 
> offer to a UA."
> 
> (I have no strong opinion on whether we use "3GPP controller needs to" 
> or "3GPP controller SHOULD".)

That works for me. My problem with the earlier text was that it described *a* solution as if it was *the* solution that would solve the problem, when there are potential problems it doesn't solve.

Changing it to be one example improves it.

There could be a longer discussion about what kinds of things could go wrong and how to mitigate each. But that may be overkill.

	Thanks,
	Paul

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

---

From: Justin Uberti <[email-masked]>
Date: Wed, 1 Dec 2021 13:19:03 -0800

Thanks Christer, I actually like the new text better as it's more flexible,
as you point out. Thumbs up from me!

On Wed, Dec 1, 2021 at 5:46 AM Christer Holmberg <
[email-masked]> wrote:

> If not, please go into compromise mode and try to suggest something that
> would make anyone happy. I really don't want the work to get delayed
> because of this.
>
> The IMPORTANT thing is to point out the PROBLEM - one endpoint sends a
> subsequent offer, and another endpoints expects an initial offer -and to
> give an EXAMPLE on how it CAN be solved. It's fine if someone wants to
> solve the problem in some other way, as long as it works...
>
> Regards,
>
> Christer
>
>
>
> That works for me. My problem with the earlier text was that it described
> *a* solution as if it was *the* solution that would solve the problem, when
> there are potential problems it doesn't solve.
>
> There could be a longer discussion about what kinds of things could go
> wrong and how to mitigate each. But that may be overkill.
>
>         Thanks,
>         Paul
>

---

From: Roman Shpount <[email-masked]>
Date: Wed, 1 Dec 2021 16:36:56 -0500

This works for me as well. I just want to make sure that the problem is
described.

Thank you, Christer.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 2 Dec 2021 07:54:32 +0000

Thank You! :)

I will submit a new version shortly.

Regards,

Christer

From: Roman Shpount <[email-masked]>
Sent: keskiviikko 1. joulukuuta 2021 23.37
To: Christer Holmberg <[email-masked]>
Cc: Paul Kyzivat <[email-masked]>; [email-masked]; Justin Uberti <[email-masked]>
Subject: Re: [MMUSIC] 1-week WGLC on Section 7.6 (3PCC Considerations) in draft-ietf-mmusic-rfc8843bis-06

This works for me as well. I just want to make sure that the problem is described.

Thank you, Christer.
_____________
Roman Shpount

On Wed, Dec 1, 2021 at 8:46 AM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Roman/Justin, can you live with the suggestion based on Paul's comment, i.e., replace:

...with:

Regards,

Christer

-----Original Message-----
From: mmusic <[email-masked]<mailto:[email-masked]>> On Behalf Of Paul Kyzivat
Sent: tiistai 30. marraskuuta 2021 18.24
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] 1-week WGLC on Section 7.6 (3PCC Considerations) in draft-ietf-mmusic-rfc8843bis-06

Christer,

        Thanks,
        Paul

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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 2 Dec 2021 08:53:38 +0000

Hi,

I just submitted a new version (-07), which implements the changes based on Paul’s comments.

Thank You to everyone who provided comments and input! :)

Regards,

Christer

From: Flemming Andreasen <[email-masked]>
Sent: maanantai 29. marraskuuta 2021 20.13
To: Christer Holmberg <[email-masked]>; [email-masked]
Cc: mmusic <[email-masked]>
Subject: Re: [MMUSIC] 1-week WGLC on Section 7.6 (3PCC Considerations) in draft-ietf-mmusic-rfc8843bis-06

On 11/29/21 11:58, Christer Holmberg wrote:
Chairs,

Can I submit a new version of the document, with the changes suggested below?

Please do. Also, did Paul Kyzivat's comments get resolved / updated ?

Thanks

-- Flemming

Regards,

Christer
________________________________
From: Justin Uberti <[email-masked]><mailto:[email-masked]>
Sent: Monday, November 29, 2021 1:46 AM
To: Roman Shpount <[email-masked]><mailto:[email-masked]>
Cc: Christer Holmberg <[email-masked]><mailto:[email-masked]>; Flemming Andreasen <[email-masked]><mailto:[email-masked]>; mmusic <[email-masked]><mailto:[email-masked]>
Subject: Re: [MMUSIC] 1-week WGLC on Section 7.6 (3PCC Considerations) in draft-ietf-mmusic-rfc8843bis-06

Looks good to me too.

On Sun, Nov 28, 2021 at 2:13 AM Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:
This still works for me.
_____________
Roman Shpount

On Sat, Nov 27, 2021 at 4:33 PM Christer Holmberg <christer.holmberg=[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Is everyone else ok with the changes?

Change #1:

Change ‘Offer’ and ‘Answer’ to ‘offer’ and ‘answer’ throughout the document.

Change #2:

OLD:

   In some 3rd Party Call Control (3PCC) scenarios a new session will be

   established between an endpoint that is currently part of an ongoing

   session and an endpoint that is currently not part of an ongoing

   session.  The endpoint that is part of a session will generate a

   subsequent SDP Offer that will be forwarded to the other endpoint by

   a 3PCC controller.  The endpoint that is not part of a session will

   process the Offer as an initial SDP Offer.

   The Session Initiation Protocol (SIP) [RFC3261<https://datatracker.ietf.org/doc/html/rfc3261>] allows a User Agent

   Client (UAC) to send a re-INVITE request without an SDP body

   (sometimes referred to as an empty re-INVITE).  In such cases, the

   User Agent Server (UAS) will include an SDP Offer in the associated

   200 (OK) response.  If the UAS is a part of an ongoing SIP session,

   it will include a subsequent offer in the 200 (OK) response.  The

   offer will be received by a 3PCC controller (UAC) and then forwarded

   to another User Agent (UA).  If the UA is not part of an ongoing SIP

   session, it will process the offer as an initial SDP Offer.

NEW:

   In some 3rd Party Call Control (3PCC) scenarios a new session will be

   established between an endpoint that is currently part of an ongoing

   session and an endpoint that is not currently part of an ongoing

   session. In this situation the endpoint that is not part of a session,

   while expecting an initial offer, can receive an SDP offer created as

   a subsequent offer. The text below describes how this can occur with

   the Session Initiation Protocol (SIP)[RFC3261<https://datatracker.ietf.org/doc/html/rfc3261>].

   SIP allows a User Agent Client (UAC) to send a re-INVITE request without

   an SDP body (sometimes referred to as an empty re-INVITE). In such cases,

   the User Agent Server (UAS) will include an SDP offer in the associated

   200 (OK) response, and when the UAS is a part of an ongoing SIP session,

   this offer will be a subsequent offer. This offer will be received

   by the 3PCC controller (UAC) and then forwarded to another User Agent (UA).

   When that UA is not part of an ongoing SIP session, as noted above,

   it will process the offer as an initial SDP Offer.

Regards,

Christer

From: mmusic <[email-masked]<mailto:[email-masked]>> On Behalf Of Justin Uberti
Sent: torstai 25. marraskuuta 2021 1.16
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Cc: Flemming Andreasen <fandreas=[email-masked]<mailto:[email-masked]>>; mmusic <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] 1-week WGLC on Section 7.6 (3PCC Considerations) in draft-ietf-mmusic-rfc8843bis-06

Good suggestion, that works for me.

On Wed, Nov 24, 2021 at 3:17 AM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Maybe we instead of saying “as described below” could say ”The text below describes how this can occur with SIP”.

That way the 1st paragraph remains independent from SIP.

Regards,

Christer

From: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Sent: tiistai 23. marraskuuta 2021 20.54
To: Justin Uberti <[email-masked]<mailto:[email-masked]>>
Cc: Christer Holmberg <[email-masked]<mailto:[email-masked]>>; Flemming Andreasen <fandreas=[email-masked]<mailto:[email-masked]>>; mmusic <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] 1-week WGLC on Section 7.6 (3PCC Considerations) in draft-ietf-mmusic-rfc8843bis-06

Justin,

Part of the reason for the non-SIP language and renaming the section was to make it clearer that it can apply to WebRTC, not just SIP. I think the goal here is to come up with the language that can be referenced from the JSEP draft, which should reduce your work.

_____________
Roman Shpount

On Tue, Nov 23, 2021 at 1:29 PM Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Nov 23, 2021 at 2:00 AM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

>>>1) for some reason, "offer" has been replaced with "Offer" throughout the document. This is a minor nit, but seems incorrect to me.
>>
>> I did that, because in the previous version we already used "BUNDLE Offer", so I thought I'd do it to be consistent.
>
> The problem though is that "answer" still is in lowercase so that introduces its own inconsistency.

Good catch. I was actually going to change that too, but now realized I forgot to.

I have no strong opinion regarding whether we use upper- or lowercase, as long as we are consistent.

> Generally I think we should avoid capitalization of common words to avoid confusion.

I can change everything to lowercase.

Sounds good.

---

>>>2) The first two paragraphs of 7.6 say similar things and it's not clear to me why they both exist. Here is my suggested revision:
>>
>> The first paragraph is more general, while the second paragraph describes how it is realized in SIP.
>
> Understood, but I feel like that intent was not totally clear in the current text.

I am mostly fine with your suggested modification.

However, as we don't really talk about "offer semantics" elsewhere in the document, perhaps:

"In this situation the endpoint that is not part of a session can receive an SDP offer, created as a
subsequent offer, while expecting an initial offer, as described below."

That works. It might be easier to understand with the "while expecting an initial offer" clause first:

"In this situation the endpoint that is not part of a session, while expecting an initial offer, can receive an SDP offer created as a

subsequent offer, as described below."

But I am fine either way.

Regards,

Christer

OLD:

   In some 3rd Party Call Control (3PCC) scenarios a new session will be
   established between an endpoint that is currently part of an ongoing
   session and an endpoint that is currently not part of an ongoing
   session.  The endpoint that is part of a session will generate a
   subsequent SDP Offer that will be forwarded to the other endpoint by
   a 3PCC controller.  The endpoint that is not part of a session will
   process the Offer as an initial SDP Offer.

   The Session Initiation Protocol (SIP) [https://datatracker.ietf.org/doc/html/rfc3261] allows a User Agent
   Client (UAC) to send a re-INVITE request without an SDP body
   (sometimes referred to as an empty re-INVITE).  In such cases, the
   User Agent Server (UAS) will include an SDP Offer in the associated
   200 (OK) response.  If the UAS is a part of an ongoing SIP session,
   it will include a subsequent offer in the 200 (OK) response.  The
   offer will be received by a 3PCC controller (UAC) and then forwarded
   to another User Agent (UA).  If the UA is not part of an ongoing SIP
   session, it will process the offer as an initial SDP Offer.

NEW:

   In some 3rd Party Call Control (3PCC) scenarios a new session will be
   established between an endpoint that is currently part of an ongoing
   session and an endpoint that is not currently part of an ongoing
   session.  In this situation the endpoint that is not part of a session
   can receive SDP with subsequent offer semantics in an initial
   SDP Offer, as described below.

   The Session Initiation Protocol (SIP) [https://datatracker.ietf.org/doc/html/rfc3261] allows a User Agent
   Client (UAC) to send a re-INVITE request without an SDP body
   (sometimes referred to as an empty re-INVITE).  In such cases, the
   User Agent Server (UAS) will include an SDP offer in the associated
   200 (OK) response, and when the UAS is a part of an ongoing SIP session,
   this offer will be a subsequent offer. This offer will be received
   by the 3PCC controller (UAC) and then forwarded to another User Agent (UA).
   When that UA is not part of an ongoing SIP session, as noted above,
   it will process the offer as an initial SDP Offer.

On Wed, Nov 17, 2021 at 3:16 PM Flemming Andreasen <fandreas=mailto:[email-masked]<mailto:[email-masked]>> wrote:
Greetings MMUSIC

We previously submitted draft-ietf-mmusic-rfc8843bis for publication, however subsequently, the issue of 3rd Party Call Control came up and as a result of that, Section 7.6 has been updated accordingly.

We are hereby starting a 1-week WGLC on Section 7.6 only in draft-ietf-mmusic-rfc8843bis-06.

If you have any comments on Section 7.6, please send those to the document authors and the MMUSIC mailing list by Wednesday November 24, 2021. If you review it but do not have any comments, please send a note to that effect as well.

Thanks

-- Flemming (MMUSIC co-chair)
_______________________________________________
mmusic mailing list
mailto:[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Roman Shpount <[email-masked]>
Date: Thu, 2 Dec 2021 18:21:24 -0500

Hi Christer,

I have reviewed the changes and there are a couple of nits:

In 7.4.1:
"answeris" should be  "answer is"

In 7.6
"In this situation the endpoint" should be "In this situation, the
endpoint" (missing comma).

"Therefore, the 3PCC controller SHOULD take actions to mitigate this
problem, e.g., by rewriting the subsequent BUNDLE offer into a valid
initial BUNDLE offer (Section 7.2), before it forwards the BUNDLE offer to
a UA."

should be

"Therefore, the 3PCC controller SHOULD take actions to mitigate this
problem, e.g., rewrite the subsequent BUNDLE offer into a valid initial
BUNDLE offer (Section 7.2), before it forwards the BUNDLE offer to a UA."

Best Regards,
_____________
Roman Shpount

On Thu, Dec 2, 2021 at 3:54 AM Christer Holmberg <christer.holmberg=
[email-masked]> wrote:

> *From:* Flemming Andreasen <[email-masked]>
> *Sent:* maanantai 29. marraskuuta 2021 20.13
> *To:* Christer Holmberg <[email-masked]>;
> [email-masked]
> *Cc:* mmusic <[email-masked]>
> *Subject:* Re: [MMUSIC] 1-week WGLC on Section 7.6 (3PCC Considerations)
> in draft-ietf-mmusic-rfc8843bis-06
>
>
>
>
>
> ------------------------------
>
> *From:* Justin Uberti <[email-masked]>
> <[email-masked]>
> *Sent:* Monday, November 29, 2021 1:46 AM
> *To:* Roman Shpount <[email-masked]> <[email-masked]>
> *Cc:* Christer Holmberg <[email-masked]>
> <[email-masked]>; Flemming Andreasen <[email-masked]>
> <[email-masked]>; mmusic <[email-masked]> <[email-masked]>
> *Subject:* Re: [MMUSIC] 1-week WGLC on Section 7.6 (3PCC Considerations)
> in draft-ietf-mmusic-rfc8843bis-06
>
>
>
> Looks good to me too.
>
>
>
> On Sun, Nov 28, 2021 at 2:13 AM Roman Shpount <[email-masked]> wrote:
>
> This still works for me.
>
> _____________
> Roman Shpount
>
>
>
>
>
> On Sat, Nov 27, 2021 at 4:33 PM Christer Holmberg <christer.holmberg=
> [email-masked]> wrote:
>
> Hi,
>
>
>
>    The Session Initiation Protocol (SIP) [RFC3261 <https://datatracker.ietf.org/doc/html/rfc3261>] allows a User Agent
>
>    the Session Initiation Protocol (SIP)[RFC3261 <https://datatracker.ietf.org/doc/html/rfc3261>].
>
>
>
> *From:* mmusic <[email-masked]> *On Behalf Of *Justin Uberti
> *Sent:* torstai 25. marraskuuta 2021 1.16
> *To:* Christer Holmberg <[email-masked]>
> *Cc:* Flemming Andreasen <fandreas=[email-masked]>; mmusic <
> [email-masked]>
> *Subject:* Re: [MMUSIC] 1-week WGLC on Section 7.6 (3PCC Considerations)
> in draft-ietf-mmusic-rfc8843bis-06
>
>
>
> On Wed, Nov 24, 2021 at 3:17 AM Christer Holmberg <
> *From:* Roman Shpount <[email-masked]>
> *Sent:* tiistai 23. marraskuuta 2021 20.54
> *To:* Justin Uberti <[email-masked]>
> *Cc:* Christer Holmberg <[email-masked]>; Flemming
> Andreasen <fandreas=[email-masked]>; mmusic <[email-masked]>
> *Subject:* Re: [MMUSIC] 1-week WGLC on Section 7.6 (3PCC Considerations)
> in draft-ietf-mmusic-rfc8843bis-06
>
>
>
> Justin,
>
>
>
> Part of the reason for the non-SIP language and renaming the section was
> to make it clearer that it can apply to WebRTC, not just SIP. I think the
> goal here is to come up with the language that can be referenced from the
> JSEP draft, which should reduce your work.
>
> _____________
> Roman Shpount
>
>
>
>
>
> On Tue, Nov 23, 2021 at 1:29 PM Justin Uberti <
> [email-masked]> wrote:
>
>
>
>
>
> On Tue, Nov 23, 2021 at 2:00 AM Christer Holmberg <
> >>>1) for some reason, "offer" has been replaced with "Offer" throughout
> the document. This is a minor nit, but seems incorrect to me.
> >>
> >> I did that, because in the previous version we already used "BUNDLE
> Offer", so I thought I'd do it to be consistent.
> >
> >>>2) The first two paragraphs of 7.6 say similar things and it's not
> clear to me why they both exist. Here is my suggested revision:
> >>
> "In this situation the endpoint that is not part of a session, while
> expecting an initial offer, can receive an SDP offer created as a
>
>    The Session Initiation Protocol (SIP) [
> https://datatracker.ietf.org/doc/html/rfc3261] allows a User Agent
>    The Session Initiation Protocol (SIP) [
> https://datatracker.ietf.org/doc/html/rfc3261] allows a User Agent
> On Wed, Nov 17, 2021 at 3:16 PM Flemming Andreasen <fandreas=mailto:
> [email-masked]> wrote:
> Greetings MMUSIC
>
> We previously submitted draft-ietf-mmusic-rfc8843bis for publication,
> however subsequently, the issue of 3rd Party Call Control came up and as a
> result of that, Section 7.6 has been updated accordingly.
>
> If you have any comments on Section 7.6, please send those to the document
> authors and the MMUSIC mailing list by Wednesday November 24, 2021. If you
> review it but do not have any comments, please send a note to that effect
> as well.
>
> Thanks
>
> mailto:[email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 Dec 2021 09:18:35 +0000

Hi Roman,

Regarding the nits in 7.4.1 and the missing comma in 7.6, I will fix as suggested.

Regarding the “rewriting” wording, I think it should be either “e.g., by rewriting” or “and e.g., rewrite”. Simply “e.g., rewrite” does not sound right to me.

But, someone who is more fluent in English than I am can of course correct me :)

Regards,

Christer

From: Roman Shpount <[email-masked]>
Sent: perjantai 3. joulukuuta 2021 1.21
To: Christer Holmberg <[email-masked]>
Cc: Flemming Andreasen <[email-masked]>; [email-masked]; mmusic <[email-masked]>
Subject: Re: [MMUSIC] 1-week WGLC on Section 7.6 (3PCC Considerations) in draft-ietf-mmusic-rfc8843bis-06

Hi Christer,

In 7.4.1:

In 7.6
"In this situation the endpoint" should be "In this situation, the endpoint" (missing comma).

"Therefore, the 3PCC controller SHOULD take actions to mitigate this problem, e.g., by rewriting the subsequent BUNDLE offer into a valid initial BUNDLE offer (Section 7.2), before it forwards the BUNDLE offer to a UA."

should be

"Therefore, the 3PCC controller SHOULD take actions to mitigate this problem, e.g., rewrite the subsequent BUNDLE offer into a valid initial BUNDLE offer (Section 7.2), before it forwards the BUNDLE offer to a UA."

Best Regards,
_____________
Roman Shpount

On Thu, Dec 2, 2021 at 3:54 AM Christer Holmberg <christer.holmberg=[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

From: Flemming Andreasen <[email-masked]<mailto:[email-masked]>>
Sent: maanantai 29. marraskuuta 2021 20.13
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: mmusic <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] 1-week WGLC on Section 7.6 (3PCC Considerations) in draft-ietf-mmusic-rfc8843bis-06

Thanks

-- Flemming

Regards,

Christer

Looks good to me too.

Hi,

Change #1:

Change #2:

OLD:

NEW:

Regards,

Christer

Hi,

Regards,

Christer

Justin,

_____________
Roman Shpount

Hi,

Sounds good.

---

Regards,

Christer

OLD:

NEW:

Thanks

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 Dec 2021 21:32:22 +0000

Hi,

Based on Roman’s comments, I have submitted a new version (-08) of 8843bis.

Regards,

Christer

From: mmusic <[email-masked]> On Behalf Of Christer Holmberg
Sent: perjantai 3. joulukuuta 2021 11.19
To: Roman Shpount <[email-masked]>
Cc: Flemming Andreasen <[email-masked]>; [email-masked]; mmusic <[email-masked]>
Subject: Re: [MMUSIC] 1-week WGLC on Section 7.6 (3PCC Considerations) in draft-ietf-mmusic-rfc8843bis-06

Hi Roman,

Regards,

Christer

Cc: Flemming Andreasen <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; mmusic <[email-masked]<mailto:[email-masked]>>

Hi Christer,

In 7.4.1:

In 7.6

should be

Best Regards,
_____________
Roman Shpount

Regards,

Christer

Thanks

-- Flemming

Regards,

Christer

Looks good to me too.

Hi,

Change #1:

Change #2:

OLD:

NEW:

Regards,

Christer

Hi,

Regards,

Christer

Justin,

_____________
Roman Shpount

Hi,

Sounds good.

---

Regards,

Christer

OLD:

NEW:

Thanks

---

From: Roman Shpount <[email-masked]>
Date: Fri, 3 Dec 2021 18:08:18 -0500

Thank you!
_____________
Roman Shpount

On Fri, Dec 3, 2021 at 4:32 PM Christer Holmberg <
[email-masked]> wrote:

> *From:* mmusic <[email-masked]> *On Behalf Of *Christer Holmberg
> *Sent:* perjantai 3. joulukuuta 2021 11.19
> *To:* Roman Shpount <[email-masked]>
> *Cc:* Flemming Andreasen <[email-masked]>; [email-masked];
> mmusic <[email-masked]>
> Regarding the “rewriting” wording, I think it should be either “e.g., by
> rewriting” or “and e.g., rewrite”. Simply “e.g., rewrite” does not sound
> right to me.
>
>
>
> *Sent:* perjantai 3. joulukuuta 2021 1.21
> *Cc:* Flemming Andreasen <[email-masked]>; [email-masked];
> mmusic <[email-masked]>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 4 Dec 2021 12:57:41 -0800

Thanks for the extra effort to clear this up.

I've reviewed the change between -04 (which the IESG approved) and -08 (the
current version) and find the changes are largely informative only, so I
don't think a second IETF-wide Last Call is necessary.  I'm going to
indicate such to the IESG and give them a few days to object; absent any
such objections, I'll release it from its IESG hold in the RFC Editor queue.

-MSK

On Fri, Dec 3, 2021 at 3:08 PM Roman Shpount <[email-masked]> wrote:

>> If you have any comments on Section 7.6, please send those to the
>> document authors and the MMUSIC mailing list by Wednesday November 24,
>> 2021. If you review it but do not have any comments, please send a note to
>> that effect as well.
>>
>> Thanks
>>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 4 Dec 2021 19:56:49 -0800

On Sat, Dec 4, 2021 at 12:57 PM Murray S. Kucherawy <[email-masked]>
wrote:

> I've reviewed the change between -04 (which the IESG approved) and -08
> (the current version) and find the changes are largely informative only, so
> I don't think a second IETF-wide Last Call is necessary.  I'm going to

It was noted that an errant "PCC" has appeared in the Abstract in -08.  You
can post a -09 without it if you like, or we can just ensure the RFC Editor
removes it prior to AUTH48.

-MSK

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 5 Dec 2021 19:53:19 +0000

Hi,

I submitted a new version (-09), where I removed “PCC” from the Abstract.

There are no other changes in the latest version.

Regards,

Christer

From: Murray S. Kucherawy <[email-masked]>
Sent: sunnuntai 5. joulukuuta 2021 5.57
To: Roman Shpount <[email-masked]>
Cc: Christer Holmberg <[email-masked]>; Flemming Andreasen <[email-masked]>; [email-masked]; Christer Holmberg <christer.holmberg=[email-masked]>; mmusic <[email-masked]>
Subject: Re: [MMUSIC] 1-week WGLC on Section 7.6 (3PCC Considerations) in draft-ietf-mmusic-rfc8843bis-06

On Sat, Dec 4, 2021 at 12:57 PM Murray S. Kucherawy <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for the extra effort to clear this up.

I've reviewed the change between -04 (which the IESG approved) and -08 (the current version) and find the changes are largely informative only, so I don't think a second IETF-wide Last Call is necessary.  I'm going to indicate such to the IESG and give them a few days to object; absent any such objections, I'll release it from its IESG hold in the RFC Editor queue.

It was noted that an errant "PCC" has appeared in the Abstract in -08.  You can post a -09 without it if you like, or we can just ensure the RFC Editor removes it prior to AUTH48.

-MSK