Subject: [payload] WGLC for draft-ietf-payload-rtp-ancillary-08

From: "Ali C. Begen" <[email-masked]>
Date: Wed, 5 Apr 2017 00:49:40 +1000

WG,

We will run another WGLC on this draft as there have been some significant
changes since we ran the WGLC earlier.

Please have a look at the draft (at least to the diff) and send your
comments to the list by April 19th.

https://datatracker.ietf.org/doc/html/draft-ietf-payload-rtp-ancillary-08

Thanks.
-acbegen (co-chair)

---

From: Roni Even <[email-masked]>
Date: Wed, 5 Apr 2017 08:06:50 +0000

Hi,
I have a  comment about section 5.
The procedure is not relevant for RTSP or SAP since it is not for declarative SDP only for SIP offer/answer when there is an answerer

Thanks
Roni Even
As individual

From: payload [mailto:[email-masked]] On Behalf Of Ali C. Begen
Sent: יום ג 04 אפריל 2017 17:50
To: [email-masked]
Subject: [payload] WGLC for draft-ietf-payload-rtp-ancillary-08

WG,

We will run another WGLC on this draft as there have been some significant changes since we ran the WGLC earlier.

Please have a look at the draft (at least to the diff) and send your comments to the list by April 19th.

Thanks.
-acbegen (co-chair)

---

From: Thomas Edwards <[email-masked]>
Date: Thu, 20 Apr 2017 05:45:32 +0000

Draft-ietf-payload-rtp-ancillary-08 Section 5 currently reads:

5.  Offer/Answer Model and Declarative Considerations

   Receivers may with to receive ANC data streams with specific DID_SDID
   parameters.  Thus when offering ANC data streams using the Session
   Description Protocol (SDP) in an Offer/Answer model [RFC3264] or in a
   declarative manner (e.g., SDP in the Real-Time Streaming Protocol
   (RTSP) [RFC2326] or the Session Announcement Protocol (SAP)
   [RFC2974]), the offerer may provide a list of ANC streams available
   with specific DID_SDID parameters in the fmtp line.  The answerer may
   respond with all or a subset of the streams offered along with fmtp
   lines with all or a subset of the DID_SDID parameters offered.  Or
   the answerer may reject the offer.  There are no restrictions on
   updating DID_SDID parameters in a subsequent offer.

Should it instead read:

5.1  Offer/Answer Model

   Receivers may wish to receive ANC data streams with specific DID_SDID
   parameters.  Thus when offering ANC data streams using the Session
   Description Protocol (SDP) in an Offer/Answer model [RFC3264], the
   offeror may provide a list of ANC streams available with specific
   DID_SDID parameters in the fmtp line.  The answerer may
   respond with all or a subset of the streams offered along with fmtp
   lines with all or a subset of the DID_SDID parameters offered.  Or
   the answerer may reject the offer.  There are no restrictions on
   updating DID_SDID parameters in a subsequent offer.

And perhaps should I add:

5.2.  Declarative SDP Considerations

   For declarative use of SDP, nothing specific is defined for this
   payload format.  The configuration given by the SDP MUST be used when
   sending and/or receiving media in the session.

Thanks!

-Thomas

--
Thomas Edwards
VP Engineering & Development
FOX Networks Engineering and Operations
[email-masked]
Phone: +1.310.369.6696
10201 West Pico Blvd.
Los Angeles, CA 90035

From: payload <[email-masked]> on behalf of Roni Even <[email-masked]>
Date: Wednesday, April 5, 2017 at 1:06 AM
To: "Ali C. Begen" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-ancillary-08

Hi,

Thanks
Roni Even
As individual

WG,

https://datatracker.ietf.org/doc/html/draft-ietf-payload-rtp-ancillary-08<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dpayload-2Drtp-2Dancillary-2D08&d=DwMGaQ&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=W247EW81XIXqaK7kzd-zibL6xtDV49HR3XrSrbOyp7Y&s=BXLdJCTurIx_shFLpgGTfp1_7g-wlfTCBo29VYBj2BI&e=>

Thanks.
-acbegen (co-chair)

---

From: John Fletcher <[email-masked]>
Date: Thu, 20 Apr 2017 10:22:47 +0000

Apologies for slightly late comments but ...

In section 2.1, definition of "C" bit, HD signals are mentioned but not UHD.  I think the definition really depends on whether the SDI interface uses separate data channels for luma and color-diff, so perhaps the specification could be re-worded along those lines.  At the very least, say "HD and UHD signals".

Specifications about RTP timestamp clock rate appear in section 3.1 as part of the media format parameters but I think these should be in section 2 as part of the timestamp definition.  Section 3.1 should just say that the Rate parameter is required.

Section 1, Introduction, uses normative word "should" in "It should be noted that".  I suggest changing to "Note that".

In section 3.1, the normative word "may" is used in "implementers may care" and "may not care".  It's not appropriate to give implementers permission or to forbid them from caring.  I suggest changing to "might".

In section 3.1, "those that must interoperate with", I suggest deleting "must".

In section 4, "the ancillary data stream may potentially contain", suggest changing to "might" to indicate possibility rather than permission.

In section 4.1, the normative word "may" is used in "implementers may wish to".  It's not appropriate to give implementers permission to wish.  I suggest deleting "to wish".

In section 5, again we have "may with", I think meant to be "may wish".  I suggest changing to "might wish" in this case.  Other uses of "may" in this section seem fine but should be capitalised.

In section 7, "It may still be a good idea", suggest changing "may" to "might".

In section 7, "receivers should take care to", I suggest deleting "take care to".

Some uses of "required" in the memo are not specifying normative requirements, suggest re-wording or changing to "needed".

Several occurrences of "may", "must", "should", "required" and "optional" are not capitalised.

Regards,
John

________________________________
From: payload [[email-masked]] on behalf of Ali C. Begen [[email-masked]]
Sent: 04 April 2017 15:49
To: [email-masked]
Subject: [payload] WGLC for draft-ietf-payload-rtp-ancillary-08

WG,

Thanks.
-acbegen (co-chair)

----------------------------

http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

---------------------

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 20 Apr 2017 17:21:04 +0000

John,
With the soon-to-be RFC https://datatracker.ietf.org/doc/draft-leiba-rfc2119-update/ (which clarifies that only CAPITALIZED keywords carry normative weight), your various points about the use of normative language in a non-normative context seem moot, no?  No language gymnastics needed.  Seems to me that ancillary draft authors had that change in mind…  or is your comment directed to a user community where capitalization of keywords does not matter (like in the IETF back in the days)?
In order to get that unambiguously right, the authors may want to change the RFC to RFC2119 to the rfc2119-update draft.  That draft shouldn’t be too long in the RFC editor’s queue anymore, so there ought to be no additional delay.
Stephan

From: payload <[email-masked]<mailto:[email-masked]>> on behalf of John Fletcher <[email-masked]<mailto:[email-masked]>>
Date: Thursday, April 20, 2017 at 03:22
To: "Ali C. Begen" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-ancillary-08

Regards,
John

________________________________
From: payload [[email-masked]<mailto:[email-masked]>] on behalf of Ali C. Begen [[email-masked]<mailto:[email-masked]>]
Sent: 04 April 2017 15:49
To: [email-masked]<mailto:[email-masked]>
Subject: [payload] WGLC for draft-ietf-payload-rtp-ancillary-08

WG,

Thanks.
-acbegen (co-chair)

http://www.bbc.co.uk

---------------------

---

From: John Fletcher <[email-masked]>
Date: Fri, 21 Apr 2017 10:26:59 +0000

This memo is likely to be used as a normative reference in a SMPTE standard.  In SMPTE documents, the normative words are not capitalised.  Therefore I think it is best that normative words are only used in a normative context, regardless of the capitalisation.

John

________________________________
From: Stephan Wenger [[email-masked]]
Sent: 20 April 2017 18:21
To: John Fletcher; Ali C. Begen; [email-masked]
Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-ancillary-08

John,

Regards,
John

WG,

Thanks.
-acbegen (co-chair)

http://www.bbc.co.uk

---------------------

http://www.bbc.co.uk

---------------------

---

From: Stephen Botzko <[email-masked]>
Date: Mon, 24 Apr 2017 13:39:57 -0400

On Fri, Apr 21, 2017 at 6:26 AM, John Fletcher <[email-masked]>
wrote:

> This memo is likely to be used as a normative reference in a SMPTE
> standard.  In SMPTE documents, the normative words are not capitalised.
> Therefore I think it is best that normative words are only used in a
> normative context, regardless of the capitalisation.
>
[sb]In my opinion that's not an IETF issue.  Clarity on what is normative
and what isn't normative is.  RFC2119-update is an option (and future
payload RFCs will be using it's conventions anyway).  So I'm with Stephan
here. [/sb]

>
> John
>
> ------------------------------
> *From:* Stephan Wenger [[email-masked]]
> *Sent:* 20 April 2017 18:21
> *To:* John Fletcher; Ali C. Begen; [email-masked]
>
> *Subject:* Re: [payload] WGLC for draft-ietf-payload-rtp-ancillary-08
>
> John,
> With the soon-to-be RFC https://datatracker.ietf.
> org/doc/draft-leiba-rfc2119-update/ (which clarifies that only
> CAPITALIZED keywords carry normative weight), your various points about the
> use of normative language in a non-normative context seem moot, no?  No
> language gymnastics needed.  Seems to me that ancillary draft authors had
> that change in mind…  or is your comment directed to a user community where
> capitalization of keywords does not matter (like in the IETF back in the
> days)?
> In order to get that unambiguously right, the authors may want to change
> the RFC to RFC2119 to the rfc2119-update draft.  That draft shouldn’t be
> too long in the RFC editor’s queue anymore, so there ought to be no
> additional delay.
> Stephan
>
> From: payload <[email-masked]> on behalf of John Fletcher <
> [email-masked]>
> In section 2.1, definition of "C" bit, HD signals are mentioned but not
> UHD.  I think the definition really depends on whether the SDI interface
> uses separate data channels for luma and color-diff, so perhaps the
> specification could be re-worded along those lines.  At the very least, say
> "HD and UHD signals".
>
> Specifications about RTP timestamp clock rate appear in section 3.1 as
> part of the media format parameters but I think these should be in section
> 2 as part of the timestamp definition.  Section 3.1 should just say that
> the Rate parameter is required.
>
> Section 1, Introduction, uses normative word "should" in "It should be
> noted that".  I suggest changing to "Note that".
>
> In section 3.1, the normative word "may" is used in "implementers may
> care" and "may not care".  It's not appropriate to give implementers
> permission or to forbid them from caring.  I suggest changing to "might".
>
> In section 4, "the ancillary data stream may potentially contain", suggest
> changing to "might" to indicate possibility rather than permission.
>
> In section 4.1, the normative word "may" is used in "implementers may wish
> to".  It's not appropriate to give implementers permission to wish.  I
> suggest deleting "to wish".
>
> In section 5, again we have "may with", I think meant to be "may wish".  I
> suggest changing to "might wish" in this case.  Other uses of "may" in this
> section seem fine but should be capitalised.
>
> Some uses of "required" in the memo are not specifying normative
> requirements, suggest re-wording or changing to "needed".
>
> ------------------------------
> *From:* payload [[email-masked]] on behalf of Ali C. Begen [
> [email-masked]]
> *Sent:* 04 April 2017 15:49
> *To:* [email-masked]
> *Subject:* [payload] WGLC for draft-ietf-payload-rtp-ancillary-08
>
> WG,
>
> This e-mail (and any attachments) is confidential and may contain personal
> views which are not the views of the BBC unless specifically stated.
> Do not use, copy or disclose the information in any way nor act in
> reliance on it and notify the sender immediately.
> This e-mail (and any attachments) is confidential and may contain personal
> views which are not the views of the BBC unless specifically stated.
> Do not use, copy or disclose the information in any way nor act in
> reliance on it and notify the sender immediately.
> _______________________________________________
> payload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/payload
>
>

---

From: John Fletcher <[email-masked]>
Date: Mon, 24 Apr 2017 17:53:54 +0000

If RFC2119-update is in force and referred to in the payload-rtp-ancillary memo, that would be OK.  But the current memo is using the old RFC2119.

I agree that clarity on what is normative and what isn't is the important thing.  One way to achieve that, and a way that will help readers more familiar with documents from other SDOs, is only to use the normative words in normative context.

John
________________________________
From: Stephen Botzko [[email-masked]]
Sent: 24 April 2017 18:39
To: John Fletcher
Cc: Stephan Wenger; Ali C. Begen; [email-masked]
Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-ancillary-08

On Fri, Apr 21, 2017 at 6:26 AM, John Fletcher <[email-masked]<mailto:[email-masked]>> wrote:

This memo is likely to be used as a normative reference in a SMPTE standard.  In SMPTE documents, the normative words are not capitalised.  Therefore I think it is best that normative words are only used in a normative context, regardless of the capitalisation.
[sb]In my opinion that's not an IETF issue.  Clarity on what is normative and what isn't normative is.  RFC2119-update is an option (and future payload RFCs will be using it's conventions anyway).  So I'm with Stephan here. [/sb]

John

________________________________
From: Stephan Wenger [[email-masked]<mailto:[email-masked]>]
Sent: 20 April 2017 18:21
To: John Fletcher; Ali C. Begen; [email-masked]<mailto:[email-masked]>

John,

Regards,
John

WG,

Thanks.
-acbegen (co-chair)

http://www.bbc.co.uk

---------------------

http://www.bbc.co.uk

---------------------

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

http://www.bbc.co.uk

---------------------

---

From: Stephen Botzko <[email-masked]>
Date: Tue, 25 Apr 2017 07:06:44 -0400

On Mon, Apr 24, 2017 at 1:53 PM, John Fletcher <[email-masked]>
wrote:

> If RFC2119-update is in force and referred to in the payload-rtp-ancillary
> memo, that would be OK.  But the current memo is using the old RFC2119.
>
I think Stephan did suggest referencing the draft RFC2119bis.

>
> I agree that clarity on what is normative and what isn't is the important
> thing.  One way to achieve that, and a way that will help readers more
> familiar with documents from other SDOs, is only to use the normative words
> in normative context.
>
I agree it is one way forward, Stephan's is another.

One can of course do both, they are not conflicting.

John
> *From:* Stephen Botzko [[email-masked]]
> *Sent:* 24 April 2017 18:39
> *To:* John Fletcher
> *Cc:* Stephan Wenger; Ali C. Begen; [email-masked]
>
>> With the soon-to-be RFC https://datatracker.ietf.o
>> rg/doc/draft-leiba-rfc2119-update/ (which clarifies that only
>> In section 4, "the ancillary data stream may potentially contain",
>> suggest changing to "might" to indicate possibility rather than permission.
>>
>> In section 4.1, the normative word "may" is used in "implementers may
>> wish to".  It's not appropriate to give implementers permission to wish.  I
>> In section 5, again we have "may with", I think meant to be "may wish".
>> I suggest changing to "might wish" in this case.  Other uses of "may" in
>> this section seem fine but should be capitalised.
>>
>> We will run another WGLC on this draft as there have been some
>> significant changes since we ran the WGLC earlier.
>>
>> This e-mail (and any attachments) is confidential and may contain
>> personal views which are not the views of the BBC unless specifically
>> stated.
>> This e-mail (and any attachments) is confidential and may contain
>> personal views which are not the views of the BBC unless specifically
>> stated.