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

[Stephan Wenger <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>> on behalf of John Fletcher <[e-mail]<mailto:[e-mail]>>
Date: Thursday, April 20, 2017 at 03:22
To: "Ali C. Begen" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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 [[e-mail]<mailto:[e-mail]>] on behalf of Ali C. Begen [[e-mail]<mailto:[e-mail]>]
Sent: 04 April 2017 15:49
To: [e-mail]<mailto:[e-mail]>
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.

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