Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05

From: Magnus Westerlund <[email-masked]>
Date: Tue, 1 Oct 2013 16:50:00 +0200

Hi Stephan,

Thanks for the comments. See inline for comments how I see these are
addressed.

WG participants, please review!

On 2013-09-26 20:07, Stephan Wenger wrote:
> Hi Magnus, group,
> 
> A few random comments.  None of them are showstoppers.  Yes, I should have
> contributed those earlier.  Sorry.
> 
> Perhaps add a section about "writing style".  Aspects here:
> (1) contrary to most other SDOs, the IETF has a history of spelling out
> not only WHAT an implementation is to do, but also WHY.  As a lot of RTP
> payload formats are written by media guys (who's home SDO is not
> necessarily the IETF), mentioning this could help overcoming a culture
> shock.

Agreed, I will include this.

> (2) OTOH, many/most implementers of RTP payload specs are the same people
> that also implement the network centric parts of the media codec--at least
> for well designed media codecs, systems, and payload formats.  Therefore,
> it is also good to reflect the style and terminology of the media codings
> pec in the payload format--even if that makes the payload spec a little
> bit less accessible for folks working only in the IETF.  This is one
> reason why I don't feel bad about the often lamented "density" of the
> H.264 payload specs.  No compromises should be made on core IETF habits
> like the use of 2119 keywords, though.

I don't see this necessarily as being contrary to 1). I think we should
recommend using the terminology of the codec to be precise and clear.
The payload formats goal is to make clear the mapping between the two
worlds, thus the whole purpose is to bind these worlds together.

> (3) It's also worth spelling out that the IETF has a historic (albeit
> arguably not current) preference for lean and mean specs, even at the cost
> of some functionality.  Most media codec SDOs operate under an assumption
> that if there were a use-case/requirement (however exotic/weak it may be,
> and I note that use/case and requirements discussions have quite often
> nothing to do with the real world) and no competing tool, a proposal goes
> in, pleasing certain IPR departments and leading to patent bonuses and
> career advancements, at the cost of a bloated document.  Some RTP payload
> formats written predominantly by media codec people arguably are bloated
> as well for the same reason.  (And yes, I take personal blame for some of
> this.)  While I do not see that we can change the situation (you want to
> have the media competence of the media coding people), I think we can at
> least point it out--hopefully in somewhat more diplomatic language--so to
> explain a very common culture clash between IETF regulars and payload
> format writers.

The RTP Payload formats may not be lean any more, but I think that is
due to the increased complexity in the codecs and the need for being
clear and explicit.

I propose that we add a section between 4.1.3 and 4.1.4 on Writing Style

My attempt for this section is the following:

4.1.4.  Writing Style

   When writing an IETF draft for an RTP payload format some few
   consideration on how to write in the IETF:

   Include Motivations:  It is common to include the motivation for why
      a particular design or technical choice was chosen.  These are
      not long statements, a sentence here and there explaining why.

   Use the Defined Terminology:  There exist defined terminology both in
      RTP and in the various media codecs.  A payload format
      specification do needs to use both to make clear the relation of
      features and their functions.

   Keeping It Simple:  IETF has a history of specifications that are
      focused on their main usage.  When it comes to RTP Payload formats
      that has a lot of modes and features the actually deployments has
      in most cases only include the most basic features that had very
      clear requirements.  Time and effort can be saved by only focusing
      on the most important use cases and keep the solution simple.

> 
> In 3.1.1 I would mention prominently the early and personal IPR disclosure
> obligations in the IETF, as these differ from other SDOs which specify
> media codecs.  Simply pointing to the policy docs may be not enough.

I agree, this should have been more clearly stated. Here are my proposal
for text around this.

  It is very important to note and understand the IETF Intellectual
   Property Rights (IPR) policy that requires early disclosures and
   disclosures based on personal knowledge from the person contributing
   in IETF.  These rules are significantly different from many other
   standardization organizations.  The IETF rules and rights associated
   with copyright and IPR are documented in BCP 78 [RFC5378] and BCP 79
   [RFC3979].  For example a person that has a patent or a patent
   application that is believed to cover a mechanism that gets added to
   the Internet draft they are contributing to (e.g. posting comments or
   suggestions on the mailing list or speaking at a meeting) they will
   need to make a timely (weeks, not months) IPR disclosure.  Read the
   above documents for the authoritative rules.  Failure to follow the
   IPR rules can have dire implications for the specification and the
   author as discussed in [RFC6701].

   The main part of the IETF process is formally defined in RFC 2026
   [RFC2026].  RFC 2418 [RFC2418] describes the WG process, the relation
   between the IESG and the WG, and the responsibilities of WG chairs
   and participants.

> 
> Section 3 (and section 1).  I think a lot of this description is written
> for someone who wants to write an RTP payload format for an existing media
> codec (with a stable and essentially unchangeable spec).  While this is
> probably still the most common scenario, there are a number of cases where
> the transport aspects of the media coder and the media aspects of the
> transport (RTP payload format) have been developed concurrently, generally
> with very pleasing results for both specs.  H.264 is one prominent
> example, but there are others.  Arguably, joint development of codec and
> RTP payload format is becoming a trend.  I think that a 2013 generation
> RTP payload how-to should acknowledge this situation.  One way to do that
> would be to include, in section 3, subsections "read and understand the
> media coding spec", and "influence the media coding spec".  If people
> think this is a good idea, I'm willing to draft a few paragraphs.

Yes, I think this is relevant to be explicit. If you can write up some
text I would be thankful, but please do so within one or maximum two weeks.

> 
> I think the 9000 byte path MTU is generally not available in home
> environments.  Instead, MTU sizes larger than the 1500 bytes (from
> Ethernet) are AFAICT, available only in a few selected (large/medium)
> enterprises and in the academic world.  If that's true, it should be
> stated.  And, in home environments, the limiting factor is often not even
> the ISP, but those old $50 router boxes (and their NAT implementations)
> that infest the world.  Mentioning this, perhaps with an informative
> reference to a recent study, would send a message: if your codec will be
> used a lot in home environments, don't go above 1500 bytes.  Not this
> year, and not next.

The message I really like to state is don't assume that 1500 bytes is
your MTU. It might be lower, and it might be higher. Design the payload
format to be flexible to allow usage in either environments.

Then there is a usage configuration that in most environment you you
need to be conservative, or maybe you should actually implement path MTU
discovery ;-).

Updated text proposal.

At the time of writing this document the most common IP Maximum
Transmission Unit (MTU) in used link layers is 1500 bytes (Ethernet data
payload). However there exist both links with smaller MTUs and links
with much larger MTUs. Certain parts of the Internet already today
support an IP MTU of 8000 bytes or more, but these are limited islands.
The most likely places to find larger MTUs than 1500 bytes are within
enterprise networks, university networks, data centers, storage networks
as well as over high capacity (10 Gbps or more) links. There is a slow
ongoing evolution towards larger MTU sizes. However, at the same time it
has become common to use tunneling protocols, often multiple ones who's
overhead when added together can shrink the MTU significant. Thus, there
exist a need to consider both limited MTUs as well as enable support of
larger MTUs. This should be considered in the design, especially in
regards to features such as aggregation of independently decodable data
units.

Note, I don't have an good reference to point at where these MTU
networks exist. This is really a speculation based on what source of
capability that exist for larger MTUs.

> 
> Sections 5.1.1 and 5.1.2: one key use case of both aggregation and
> fragmentation is the effective packetization of pre-recorded content,
> where one cannot change the size of ADUs without transcoding.   The key
> use case of aggregation is the packetization overhead for small ADUs such
> as parameter sets or SEI messages in H.264.

Yes, I have tried to make these clearer in the below text.

5.1.1.  Aggregation

   Aggregation allows for the inclusion of multiple application data
   units (ADUs) within the same RTP payload.  This is commonly supported
   for codecs that produce ADUs of sizes smaller than the IP MTU.  Do
   remember that the MTU may be significantly larger than 1500 bytes.
   An MTU of 9000 bytes is available today and an MTU of 64k may be
   available in the future.  Many speech codecs have the property of
   ADUs of a few fixed sizes.  Video encoders may generally produce ADUs
   of quite flexible sizes.  Thus the need for aggregation may be less.
   But some codecs produces small ADUs mixed with large, for example
   H.264 SEI messages.  Sending individual SEI message in separate
   packets are not efficient compared to combing the with other ADUs.
   There also exist cases when the ADUs are pre-produced and can't be
   adopted to a specific networks MTU.  Instead their packetization
   needs to be adopted to the network.  Thus there exist some different
   use cases with the possibility to aggregate multiple ADUs, including
   for different playback times, is useful.

   The main disadvantage of aggregation is the extra delay introduced
   (due to buffering until a sufficient number of ADUs have been
   collected at the sender) and reduced robustness against packet loss.
   Aggregation also introduces buffering requirements at the receiver.

5.1.2.  Fragmentation

   If the real-time media format has the property that it may produce
   ADUs that are larger than common MTU sizes then fragmentation support
   should be considered.  An RTP Payload format may always fall back on
   IP fragmentation, however as discussed in RFC 2736 this has some
   drawbacks.  Mainly that IP fragmented packets commonly are discarded
   in the network, especially by Network Address Translators or
   Firewalls.  The usage of RTP payload format-level fragmentation
   allows for more efficient usage of RTP packet loss recovery
   mechanisms.  It may also in some cases also allow better usage of
   partial ADUs by doing media specific fragmentation at media specific
   boundaries.  In use cases where the ADUs are pre-produced and can't
   be adopted to the network support for fragmentation can be crucial.

> 
> In a different email, you asked for review of 5.1.5.  There are more
> qualified people on this list to comment, but here are a few points.
> (1) citing H.264 RFC 6184 for temporal scalability is a bit questionable,
> as 6184 doe snot include a single mechanism to support temporal
> scalability (although H.264 does).  So if people would go to 6184 as the
> payload format for base H.264 and read it, expecting ideas on how to deal
> with temporal scalability, they would come up blank after digging through
> 101 pages of not exactly easy to read spec language.  I fear that it would
> be best to point to SVC and 6190 for temporal scalability, just as it is
> done for spatial and SNR.

I think there is a point that tempoeral scalability can simply be done,
without explicit definition. But it should be clear that this is may
also be more explictly defined as in SVC.

> (2) with respect to MST: the doc could be read that re-alignment for
> H.264-SVC could be implemented through 6051.  This is not the case, as
> decoding time and NAL unit order are mostly decoupled (not only in SVC,
> but in all modern video codecs).

Agreed, this is poorly formulated. I will try to make it clear that for
certain features an payload format design could rely on these tools to
be part of solution. The changed wording is:

                                                ... In order to allow
   correct data provision to a decoder after reception from different
   sessions, data re-alignment mechanisms are described for Scalable
   Video Coding [RFC6190].  There exist some generic tools that may be
   of use for a payload format design for a scalable codec.  These
   include the Rapid Sync for RTP flows [RFC6051], which is using
   existing RTP mechanisms, i.e. the NTP timestamp, to ensure timely
   inter-session synchronization.  Another is the signaling feature for
   indicating dependencies of RTP sessions in SDP, as defined in the
   Media Decoding Dependency Grouping in SDP [RFC5583].

> (3) Perhaps write something to the extent that MST was unpopular because
> of the impracticality of multiple transport addresses, and that this
> reason is slowly going away through IETF-acceptance of RTP mux techniques.

I think we need to be clear here. SVC MST mode appears to have gotten
significant use as multiple packet streams (SSRCs) within a single RTP
session. The original envision of the MST mode was for multicast or
other receiver controlled steering of what flows was received. From my
perspective any future scalable codec should consider having both a
single stream and a multi stream mode. However, the mapping of the RTP
packet streams needs to be flexible to cater both for multiple RTP
sessions and then commonly multicast groups as well as within a single
RTP session.

> 
> Section 6.2, "recent" VC-1.  You probably wanted to cite VP8?  Calling
> VC-1 and its payload spec "recent" is a bit of  a stretch.

Failure to keep the text current. This text was first included back in
2008. Haven't been in a hurry to finish this document. But now it is time.

I updated this text to say:
The definition of RTP payload formats for video has seen an evolution
from the early ones such as H.261 towards the latest for VP-8 and
H.265/HEVC.

> 
> Perhaps add a "Do and don't" sections listing key mistakes.  In the don't
> section, list the handling of the timestamp in RFCs 2038 and 2250.

This is WG last call, of a document that has been a WG document since
2006 (then in AVT). This proposal although a good idea, is a little bit
late to introduce. Primarily as I think such a section would require a
couple of rounds of revision before getting right.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 1 Oct 2013 17:17:01 +0000

Hi Magnus, all,
Thanks for taking my suggestions into account.  Your updates are fine,
plus/minus massaging the language a bit (Magnus, I'll send you suggestions
in private).

>text I would be thankful, but please do so within one or maximum two

How about two hours later :-)

3.x Read and understand the media coding spec
It may be obvious, but it is necessary for an author of an RTP payload
specification 
to have a solid understanding of the media to be transported.  Important
are not only 
the specifically spelled out transport aspects (if any) in the media
coding spec, but also
core concepts of the underlying technology.  For example, an RTP payload
format for 
video coded with inter picture prediction will perform poorly if the
payload
designer does not take the use of inter picture prediction into account.
OTOH, some
(mostly older) media codecs offer "error resilience" tools against bit
errors, which,
when misemployed over RTP, in almost all cases would only introduce
overhead with no 
measurable return.

3.x Joint development of media coding spec and RTP payload format
In the last decade there have been a few cases where the media codec and
the associated 
RTP payload format have been developed concurrently and jointly.
Developing the two specs
not only concurrently but also jointly, in close cooperation with the
group developing
The media codec, allows to leverage the benefits joint source/channel
coding can provide.
Doing so has historically resulted in well performing payload formats and
in success of
both media coding spec and associated RTP payload format.  Insofar,
whenever the opportunity
presents it, it may be useful to closely keep the media coding group in
the loop (through
appropriate liaison means whatever those may be) and influence the media
coding spec to 
be RTP friendly.  One example for such a media coding spec is H.264, where
the RTP payload
header co-serves as the H.264 NAL unit header and vice versa, and is
documented in both
specs.

Stephan

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 2 Oct 2013 09:50:15 +0200

Thanks for the text proposal

Also thank for the text edits provided privately. To allow anyone in the
WG to review these I have submitted and updated draft version. Please
comment within a week if you think these edits are acceptable. If not,
explicit changes are preferred.

> when misemployed over RTP, in almost all cases would only introduce

I put this as the new 3.1.

> header co-serves as the H.264 NAL unit header and vice versa, and is

I put this last in section 4, as Section 4.4.

cheers

Magnus Westerlund

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 15 Oct 2013 14:15:36 +0000

Just got round to looking at this.

I regard to the IPR considerations, I think some distinction should be made between IPR that is essential to implement the codec, and that which is essential to implement the payload format.

Clearly the latter should be declared.

I believe in the past we have had also declarations which appear to relate to the former, which while not wrong, I think just add to the confusion. Such declarations should belong to the SDO specifying the codec.

Regards

Keith 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Magnus Westerlund
> Sent: 01 October 2013 15:50
> To: Stephan Wenger
> Cc: [email-masked]
> Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05
> 
> Hi Stephan,
> 
> Thanks for the comments. See inline for comments how I see 
> these are addressed.
> 
> > A few random comments.  None of them are showstoppers.  
> Yes, I should 
> > have contributed those earlier.  Sorry.
> > 
> > (1) contrary to most other SDOs, the IETF has a history of spelling 
> > out not only WHAT an implementation is to do, but also WHY. 
>  As a lot 
> > of RTP payload formats are written by media guys (who's home SDO is 
> > not necessarily the IETF), mentioning this could help overcoming a 
> > culture shock.
> 
> > (2) OTOH, many/most implementers of RTP payload specs are the same 
> > people that also implement the network centric parts of the media 
> > codec--at least for well designed media codecs, systems, 
> and payload 
> > formats.  Therefore, it is also good to reflect the style and 
> > terminology of the media codings pec in the payload format--even if 
> > that makes the payload spec a little bit less accessible for folks 
> > working only in the IETF.  This is one reason why I don't feel bad 
> > about the often lamented "density" of the
> > H.264 payload specs.  No compromises should be made on core IETF 
> > habits like the use of 2119 keywords, though.
> 
> I don't see this necessarily as being contrary to 1). I think 
> we should recommend using the terminology of the codec to be 
> precise and clear.
> The payload formats goal is to make clear the mapping between 
> the two worlds, thus the whole purpose is to bind these 
> worlds together.
> 
> 
> > arguably not current) preference for lean and mean specs, 
> even at the 
> > cost of some functionality.  Most media codec SDOs operate under an 
> > assumption that if there were a use-case/requirement (however 
> > exotic/weak it may be, and I note that use/case and requirements 
> > discussions have quite often nothing to do with the real 
> world) and no 
> > competing tool, a proposal goes in, pleasing certain IPR 
> departments 
> > and leading to patent bonuses and career advancements, at 
> the cost of 
> > a bloated document.  Some RTP payload formats written 
> predominantly by 
> > media codec people arguably are bloated as well for the 
> same reason.  
> > (And yes, I take personal blame for some of
> > this.)  While I do not see that we can change the situation 
> (you want 
> > to have the media competence of the media coding people), I 
> think we 
> > can at least point it out--hopefully in somewhat more diplomatic 
> > language--so to explain a very common culture clash between IETF 
> > regulars and payload format writers.
> 
> The RTP Payload formats may not be lean any more, but I think 
> that is due to the increased complexity in the codecs and the 
> need for being clear and explicit.
> 
> 
> > In 3.1.1 I would mention prominently the early and personal IPR 
> > disclosure obligations in the IETF, as these differ from other SDOs 
> > which specify media codecs.  Simply pointing to the policy 
> docs may be not enough.
> 
> I agree, this should have been more clearly stated. Here are 
> my proposal for text around this.
> 
> > Section 3 (and section 1).  I think a lot of this description is 
> > written for someone who wants to write an RTP payload format for an 
> > existing media codec (with a stable and essentially unchangeable 
> > spec).  While this is probably still the most common 
> scenario, there 
> > are a number of cases where the transport aspects of the 
> media coder 
> > and the media aspects of the transport (RTP payload format) 
> have been 
> > developed concurrently, generally with very pleasing 
> results for both 
> > specs.  H.264 is one prominent example, but there are others.  
> > Arguably, joint development of codec and RTP payload format is 
> > becoming a trend.  I think that a 2013 generation RTP 
> payload how-to 
> > should acknowledge this situation.  One way to do that would be to 
> > include, in section 3, subsections "read and understand the media 
> > coding spec", and "influence the media coding spec".  If 
> people think this is a good idea, I'm willing to draft a few 
> paragraphs.
> 
> Yes, I think this is relevant to be explicit. If you can 
> write up some text I would be thankful, but please do so 
> within one or maximum two weeks.
> 
> > 
> > stated.  And, in home environments, the limiting factor is 
> often not 
> > even the ISP, but those old $50 router boxes (and their NAT 
> > implementations) that infest the world.  Mentioning this, 
> perhaps with 
> > an informative reference to a recent study, would send a 
> message: if 
> > your codec will be used a lot in home environments, don't go above 
> > 1500 bytes.  Not this year, and not next.
> 
> The message I really like to state is don't assume that 1500 
> bytes is your MTU. It might be lower, and it might be higher. 
> Design the payload format to be flexible to allow usage in 
> either environments.
> 
> Then there is a usage configuration that in most environment 
> you you need to be conservative, or maybe you should actually 
> implement path MTU discovery ;-).
> 
> Updated text proposal.
> 
> At the time of writing this document the most common IP 
> Maximum Transmission Unit (MTU) in used link layers is 1500 
> bytes (Ethernet data payload). However there exist both links 
> with smaller MTUs and links with much larger MTUs. Certain 
> parts of the Internet already today support an IP MTU of 8000 
> bytes or more, but these are limited islands.
> The most likely places to find larger MTUs than 1500 bytes 
> are within enterprise networks, university networks, data 
> centers, storage networks as well as over high capacity (10 
> Gbps or more) links. There is a slow ongoing evolution 
> towards larger MTU sizes. However, at the same time it has 
> become common to use tunneling protocols, often multiple ones 
> who's overhead when added together can shrink the MTU 
> significant. Thus, there exist a need to consider both 
> limited MTUs as well as enable support of larger MTUs. This 
> should be considered in the design, especially in regards to 
> features such as aggregation of independently decodable data units.
> 
> Note, I don't have an good reference to point at where these 
> MTU networks exist. This is really a speculation based on 
> what source of capability that exist for larger MTUs.
> 
> > 
> > use case of aggregation is the packetization overhead for 
> small ADUs 
> > such as parameter sets or SEI messages in H.264.
> 
> > (1) citing H.264 RFC 6184 for temporal scalability is a bit 
> > questionable, as 6184 doe snot include a single mechanism 
> to support 
> > temporal scalability (although H.264 does).  So if people 
> would go to 
> > 6184 as the payload format for base H.264 and read it, 
> expecting ideas 
> > on how to deal with temporal scalability, they would come up blank 
> > after digging through
> > 101 pages of not exactly easy to read spec language.  I 
> fear that it 
> > would be best to point to SVC and 6190 for temporal 
> scalability, just 
> > as it is done for spatial and SNR.
> 
> I think there is a point that tempoeral scalability can 
> simply be done, without explicit definition. But it should be 
> clear that this is may also be more explictly defined as in SVC.
> 
> 
> > decoding time and NAL unit order are mostly decoupled (not only in 
> > SVC, but in all modern video codecs).
> 
> Agreed, this is poorly formulated. I will try to make it 
> clear that for certain features an payload format design 
> could rely on these tools to be part of solution. The changed 
> wording is:
> 
>                                                 ... In order to allow
> > (3) Perhaps write something to the extent that MST was unpopular 
> > because of the impracticality of multiple transport addresses, and 
> > that this reason is slowly going away through 
> IETF-acceptance of RTP mux techniques.
> 
> I think we need to be clear here. SVC MST mode appears to 
> have gotten significant use as multiple packet streams 
> (SSRCs) within a single RTP session. The original envision of 
> the MST mode was for multicast or other receiver controlled 
> steering of what flows was received. From my perspective any 
> future scalable codec should consider having both a single 
> stream and a multi stream mode. However, the mapping of the 
> RTP packet streams needs to be flexible to cater both for 
> multiple RTP sessions and then commonly multicast groups as 
> well as within a single RTP session.
> 
> 
> > 
> Failure to keep the text current. This text was first 
> included back in 2008. Haven't been in a hurry to finish this 
> document. But now it is time.
> 
> The definition of RTP payload formats for video has seen an 
> evolution from the early ones such as H.261 towards the 
> latest for VP-8 and H.265/HEVC.
> 
> 
> > 
> > Perhaps add a "Do and don't" sections listing key mistakes.  In the 
> > don't section, list the handling of the timestamp in RFCs 
> 2038 and 2250.
> 
> 2006 (then in AVT). This proposal although a good idea, is a 
> little bit late to introduce. Primarily as I think such a 
> section would require a couple of rounds of revision before 
> getting right.
> 
> Cheers
> 
> 
> Magnus Westerlund
> 
> _______________________________________________
> payload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/payload
>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 16 Oct 2013 08:39:04 +0200

On 2013-10-15 16:15, DRAGE, Keith (Keith) wrote:
> I regard to the IPR considerations, I think some distinction should
> be made between IPR that is essential to implement the codec, and
> that which is essential to implement the payload format.
> 
> I believe in the past we have had also declarations which appear to
> relate to the former, which while not wrong, I think just add to the
> confusion. Such declarations should belong to the SDO specifying the
> codec.

Yes, I agree with you. This should be clarified. Do you have a some text
proposal?

Consider where we are in the process I think it is good if we agree on
some formulation here on the list, then I can incorporate it.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 17 Oct 2013 08:21:45 +0200

> Yes, I agree with you. This should be clarified. Do you have a some text

WG,

I propose that we add this text as a indented note after the second
paragraph of Section 3.2.1:

Note: These IPR rules applies on what is written in the RTP Payload
format Internet Draft (and later RFC), IPRs that relates to a codec
specification from an external body does not require IETF IPR disclosure.

Is this okay, and appropriate to deal with this comment?

Cheers

Magnus Westerlund

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 17 Oct 2013 10:47:33 +0000

The proposal is, in principal, fine. Perhaps "on what is written" could be a bit more specific to be "on the requirements". Informative text explaining the nature of the codec would not normally require an IETF IPR declaration.

I would also add a sentence something like:

"Appropriate IPR declarations for the codec itself would normally be found in files of the external body defining the codec, in accordance with that external bodies own IPR rules."

Regards

Keith

> From: Magnus Westerlund [mailto:[email-masked]] 
> Sent: 17 October 2013 07:22
> To: DRAGE, Keith (Keith); Stephan Wenger
> Cc: [email-masked]
> > Yes, I agree with you. This should be clarified. Do you have a some 
> > text proposal?
> 
> WG,
> 
> I propose that we add this text as a indented note after the 
> second paragraph of Section 3.2.1:
> 
> Note: These IPR rules applies on what is written in the RTP 
> Payload format Internet Draft (and later RFC), IPRs that 
> relates to a codec specification from an external body does 
> not require IETF IPR disclosure.
>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 17 Oct 2013 13:05:19 +0200

On 2013-10-17 12:47, DRAGE, Keith (Keith) wrote:
> The proposal is, in principal, fine. Perhaps "on what is written"
> could be a bit more specific to be "on the requirements". Informative
> text explaining the nature of the codec would not normally require an
> IETF IPR declaration.
> 
> "Appropriate IPR declarations for the codec itself would normally be
> found in files of the external body defining the codec, in accordance
> with that external bodies own IPR rules."
> 

Maybe using "specified" is better than what payload format requires?
Anyway, updated text proposal:

Note: These IPR rules applies on what is specified in the RTP Payload
format Internet Draft (and later RFC), IPRs that relates to a codec
specification from an external body does not require IETF IPR
disclosure. Informative text explaining the nature of the codec would
not normally require an IETF IPR declaration. Appropriate IPR
declarations for the codec itself would normally be found in files of
the external body defining the codec, in accordance with that external
bodies own IPR rules.

Cheers

Magnus Westerlund

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 17 Oct 2013 11:05:48 +0000

Fine.

Keith 

> Sent: 17 October 2013 12:05
> Note: These IPR rules applies on what is specified in the RTP 
> not require IETF IPR disclosure. Informative text explaining 
> the nature of the codec would not normally require an IETF 
> IPR declaration. Appropriate IPR declarations for the codec 
> itself would normally be found in files of the external body 
> defining the codec, in accordance with that external bodies 
> own IPR rules.
> 
> Cheers
> 
> Magnus Westerlund
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 18 Oct 2013 15:33:53 +0000

> Note: These IPR rules applies on what is specified in the RTP Payload

s/ applies/apply

> format Internet Draft (and later RFC), IPRs that relates to a codec

s/ relates/relate

> specification from an external body does not require IETF IPR

s/ does/do

> the external body defining the codec, in accordance with that external

s/bodies/body's

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 21 Oct 2013 07:45:18 +0200

Hi,

I will not submit this proposal included in a version before the
dead-line. The reason is that I want to discuss this with my legal
department.

Secondly, I think the WG should consider the implication of even this
informative words about how it has been usually done. This group is not
changing the IETF process in regards to the IPR. So are we really
certain that we are not misrepresenting a reasonable interpretation of
the IPR rules of IETF?

cheers

Magnus

-- 

Magnus Westerlund

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 21 Oct 2013 12:53:39 +0000

Not sure which words you are having problems with.

A reasonable interpretation of the IETF rules is that anyone can declare anything against any internet-draft / RFC.

What we are concentrating on here is relevance, i.e. people can only be required to declare essential IPR against what is covered by the document,a nd that you cannot be expected to find all the codec IPR declarations being made against the payload type definition.

Keith 

> Sent: 21 October 2013 06:45
> To: Magnus Westerlund; DRAGE, Keith (Keith); Stephan Wenger
> Cc: [email-masked]
> I will not submit this proposal included in a version before 
> the dead-line. The reason is that I want to discuss this with 
> my legal department.
> 
> Secondly, I think the WG should consider the implication of 
> even this informative words about how it has been usually 
> done. This group is not changing the IETF process in regards 
> to the IPR. So are we really certain that we are not 
> misrepresenting a reasonable interpretation of the IPR rules of IETF?
> 
> cheers
> 
> Magnus
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 21 Oct 2013 16:34:15 +0200

On 2013-10-21 14:53, DRAGE, Keith (Keith) wrote:
> A reasonable interpretation of the IETF rules is that anyone can
> declare anything against any internet-draft / RFC.
> 
> What we are concentrating on here is relevance, i.e. people can only
> be required to declare essential IPR against what is covered by the
> document,a nd that you cannot be expected to find all the codec IPR
> declarations being made against the payload type definition.

I was worried about making a interpretation beyond the existing rules,
and thus warping the rules.

I have now submitted a new version with the note. I have done two other
changes in the same section. First a rewording that makes it clear that
IETF rules may be different compared to what you are used to. I also
removed the time expression in regards to timely disclosure, as the
rules are not providing any exact time frames.

Cheers

Magnus Westerlund