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

On Mon, Apr 24, 2017 at 1:53 PM, John Fletcher <John.Fletcher@bbc.co.uk>
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 [stephen.botzko@gmail.com]
> *Sent:* 24 April 2017 18:39
> *To:* John Fletcher
> *Cc:* Stephan Wenger; Ali C. Begen; payload@ietf.org
>
> *Subject:* Re: [payload] WGLC for draft-ietf-payload-rtp-ancillary-08
>
>
>
> On Fri, Apr 21, 2017 at 6:26 AM, John Fletcher <John.Fletcher@bbc.co.uk>
> 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 [stewe@stewe.org]
>> *Sent:* 20 April 2017 18:21
>> *To:* John Fletcher; Ali C. Begen; payload@ietf.org
>>
>> *Subject:* Re: [payload] WGLC for draft-ietf-payload-rtp-ancillary-08
>>
>> John,
>> With the soon-to-be RFC https://datatracker.ietf.o
>> rg/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 <payload-bounces@ietf.org> on behalf of John Fletcher <
>> John.Fletcher@bbc.co.uk>
>> Date: Thursday, April 20, 2017 at 03:22
>> To: "Ali C. Begen" <ali.begen@networked.media>, "payload@ietf.org" <
>> payload@ietf.org>
>> Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-ancillary-08
>>
>> 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 [payload-bounces@ietf.org] on behalf of Ali C. Begen [
>> ali.begen@networked.media]
>> *Sent:* 04 April 2017 15:49
>> *To:* payload@ietf.org
>> *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.
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-payload-rtp-ancillary-08
>>
>> 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.
>>
>> ---------------------
>>
>>
>>
>> ----------------------------
>>
>> 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.
>>
>> ---------------------
>>
>> _______________________________________________
>> payload mailing list
>> payload@ietf.org
>> https://www.ietf.org/mailman/listinfo/payload
>>
>>
>
>
> ----------------------------
>
> 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.
>
> ---------------------
>