Subject: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-t140-usage-data-channel-12: (with DISCUSS)

From: Magnus Westerlund via Datatracker <[email-masked]>
Date: Tue, 07 Apr 2020 05:30:06 -0700

Magnus Westerlund has entered the following ballot position for
draft-ietf-mmusic-t140-usage-data-channel-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-t140-usage-data-channel/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Section 4.1:

   The offerer and answerer MUST NOT include the max-retr or the max-
   time attribute parameters in the 'dcmap' attribute.

This is just an example of a issue that is exists in basically all of the RFC
2119 terminolgy using sentences in this section. The formulation is that the
offerer or answerer must do something with attributes or parameters of the
dcmap attribute. However, it is not stated to be specific to the dcmap
attribute that specifically specify something for a T.140 SCTP stream. I think
that scope restriction needs to be made more explicit for these RFC 2119
statements. Else they would have applicability as soon as one support this
specification.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 Apr 2020 12:58:02 +0000

Hi Magnus,

Thank You for the review! Please see inline.

>    statements. Else they would have applicability as soon as one support this
  
The last sentence of Section 4 says:

"This section defines the SDP considerations that are specific to a T.140 data channel."

Regards,

Christer

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 7 Apr 2020 14:51:12 +0000

Hi Christer,

> Thank You for the review! Please see inline.

So why is that last and not first? So isn't this all scoped based on that there
is an dcsmap line with a subprotocol line stating t140 either included in an
offer that one is generating or responding to as an answerer? 

As you see I am undertain if the sentence is sufficient to scope this correctly.
Are there statement that are relevant outside of the scope of actually offering
or answering a T140 offer? I think part of the uncertainty is if there are
aspect that my be wrongly interpreted if one support T140 but it is not actively
included? 

Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 Apr 2020 15:05:43 +0000

Hi,

    >>>    This is just an example of a issue that is exists in basically all of the
    >>>    RFC 2119 terminolgy using sentences in this section. The formulation is that
    >>>    the offerer or answerer must do something with attributes or parameters of
    >>>    the dcmap attribute. However, it is not stated to be specific to the dcmap
    >>>    attribute that specifically specify something for a T.140 SCTP stream. I
    >>>    think that scope restriction needs to be made more explicit for these RFC 2119
    >>>    statements. Else they would have applicability as soon as one support
    >>>    this specification.
    >>   
    > So why is that last and not first? 

    It is the last sentence of the parent section (4), and covers the procedures in the section, including the subsections (4.x). This wording has been used multiple times before.

    But, if you think it is more clear, I could say "The following sub sections define the SDP considerations....".

    > So isn't this all scoped based on that there is an dcsmap line with a subprotocol line stating t140 either included in an

    Correct, and Section 4.1 describes the SDP details on how to indicate a T.140 data channel, using the dcmap attribute.
    
    > aspect that my be wrongly interpreted if one support T140 but it is not actively

    The procedures in section 4 (including the sub sections) only apply to T140.

   Regards,

   Christer

    Cheers
    
    Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 9 Apr 2020 09:00:21 +0000

Hi,

I will clear my discuss as I think I strayed beyond the discuss criteria due
missing the sentence in the prior sub-section. 

I think the text would clearer if one took slightly more consideration for under
what conditions in offers or answers the normative language will apply. For
exmaple. When an a=dcmap:3 with a subprotocol="t140" attribute is included ...

This is of course statement dependent and I will not spend my time on suggesting
rewording of all of these. 

Cheers

Magnus

On Tue, 2020-04-07 at 15:05 +0000, Christer Holmberg wrote:
>     >> "This section defines the SDP considerations that are specific to a
> T.140 data
>     >> channel."
>     >
>     It is the last sentence of the parent section (4), and covers the
> procedures in the section, including the subsections (4.x). This wording has
> been used multiple times before.
> 
>     But, if you think it is more clear, I could say "The following sub
> sections define the SDP considerations....".
> 
>     > So isn't this all scoped based on that there is an dcsmap line with a
> subprotocol line stating t140 either included in an
>     Correct, and Section 4.1 describes the SDP details on how to indicate a
> T.140 data channel, using the dcmap attribute.
>     
-- 
Cheers

Magnus Westerlund

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 9 Apr 2020 11:08:54 +0000

Hi Magnus,
    
>    rewording of all of these. 
  
What about the following change:

OLD:

NEW:

	"This section, and its subsections, define the SDP considerations that are specific to a T.140 data channel,
	  identified by an SDP 'dcmap' attribute [I-D.ietf-mmusic-data-channel-sdpneg]  with a "t140" 
                attribute parameter value."
	
Regards,

Christer

    -- 
    Cheers
    
    Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 9 Apr 2020 11:51:16 +0000

Hi Christer.

I think the below proposal improves the scope description so it would be good to
include. 

Thanks

Magnus

On Thu, 2020-04-09 at 11:08 +0000, Christer Holmberg wrote:
> T.140 data channel."
>     >     >>>       The offerer and answerer MUST NOT include the max-retr or
> the
>     > max-
>     >     >>>    This is just an example of a issue that is exists in
> basically all
>     > of the
>     >     >>>    the dcmap attribute. However, it is not stated to be specific
> to
>     > the dcmap
>     >     >>>    attribute that specifically specify something for a T.140
> SCTP
>     > stream. I
>     >     >>>    think that scope restriction needs to be made more explicit
> for
>     > these RFC 2119
>     >     > As you see I am undertain if the sentence is sufficient to scope
> this
>     > correctly.
>     >     > Are there statement that are relevant outside of the scope of
> actually
>     > offering
>     >     > or answering a T140 offer? I think part of the uncertainty is if
> there
>     > are
>     >     > aspect that my be wrongly interpreted if one support T140 but it
> is not
>     > actively
>     >     > included? 
>     > 
>     >     The procedures in section 4 (including the sub sections) only apply
> to
>     > T140.
>     > 
>     >    Regards,
>     > 
>     >    Christer
>     > 
>     > 
>     > 
>     > 
>     >     Cheers
>     >     
>     >     Magnus Westerlund 
>     >     
>     >     
-- 
Cheers

Magnus Westerlund

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 9 Apr 2020 12:00:03 +0000

Hi,
    
    > I think the below proposal improves the scope description so it would be good to include.

    Done :)

    https://github.com/cdh4u/draft-datachannel-t140/pull/56/commits/a6a5ed91c20439bab709c89cfba725656e0bb22a

    Regards,

    Christer

    -- 
    Cheers
    
    Magnus Westerlund