Re: [AVTCORE] I-D Action: draft-ietf-avtext-framemarking-08.txt

Hi Magnus,

Version 09 addresses your two issues below. Please review and confirm if
this resolves all your issues.

https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-framemarking-09


Thanks,
Mo

-----Original Message-----
From: mzanaty <[email protected]>
Date: Friday, November 9, 2018 at 4:25 PM
To: 'Magnus Westerlund' <[email protected]>, "[email protected]"
<[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtext-framemarking-08.txt
Resent-From: <[email protected]>
Resent-To: mzanaty <[email protected]>, Espen Berger <[email protected]>,
<[email protected]>
Resent-Date: Friday, November 9, 2018 at 4:25 PM

Hi Magnus,

For clarity, we will add diagrams for the long header format when any
fields are omitted.
(L=1 when TL0PICIDX is omitted, and L=0 when both LID and TL0PICIDX are
omitted).

Thanks,
Mo

-----Original Message-----
From: avt <[email protected]> on behalf of 'Magnus Westerlund'
<[email protected]>
Date: Tuesday, November 6, 2018 at 2:49 AM
To: "[email protected]" <[email protected]>,
"[email protected]"
<[email protected]>
Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtext-framemarking-08.txt

Hi,

I have reviewed the changes and have some comments below. Otherwise
thanks for addressing my comments.

1. Section 3.1:

Note that this SHOULD match the RTP header
      marker bit when the latter is reliable.

So, should this really be a capital SHOULD? First it appears to be an
informative note. Secondly, video payload formats has so far used the
marker bit to indicate last packet of a frame/field (for interleaved).
But, that doesn't preclude that a future format would depart from the
convention. Thus, some rewording may be suitable.

2. Section 3.2

One issue was not resolved from my previous comment:

The ID is assigned per [RFC8285],
   and the length is encoded as L=2 which indicates 3 octets of data.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  ID=? |  L=2  |S|E|I|D|B| TID |   LID         |    TL0PICIDX  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  LID: Layer ID (8 bits) - Identifies the spatial and quality layer
      encoded, starting with 0 and increasing with higher fidelity.  If
      no scalability is used, this MUST be 0 or omitted to reduce
      length.  When omitted, TL0PICIDX MUST also be omitted.

The issue I see with the LID text is that they it says that the LID
field and the TL0PICIDX can be omitted, and thus have a shorter header.
To allow for this, one need to change the upper part for the long header
and the allowed values for the L field can be either 0 or 2.

Cheers

Magnus


On 2018-10-24 02:19, [email protected] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
> This draft is a work item of the Audio/Video Transport Core Maintenance
>WG of the IETF.
>
>         Title           : Frame Marking RTP Header Extension
>         Authors         : Mo Zanaty
>                           Espen Berger
>                           Suhas Nandakumar
> 	Filename        : draft-ietf-avtext-framemarking-08.txt
> 	Pages           : 12
> 	Date            : 2018-10-23
>
> Abstract:
>    This document describes a Frame Marking RTP header extension used to
>    convey information about video frames that is critical for error
>    recovery and packet forwarding in RTP middleboxes or network nodes.
>    It is most useful when media is encrypted, and essential when the
>    middlebox or node has no access to the media decryption keys.  It is
>    also useful for codec-agnostic processing of encrypted or unencrypted
>    media, while it also supports extensions for codec-specific
>    information.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-avtext-framemarking/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-avtext-framemarking-08
> https://datatracker.ietf.org/doc/html/draft-ietf-avtext-framemarking-08
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-framemarking-08
>
>
> Please note that it may take a couple of minutes from the time of
>submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email protected]
> https://www.ietf.org/mailman/listinfo/avt
>

-- 

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email protected]
----------------------------------------------------------------------


_______________________________________________
Audio/Video Transport Core Maintenance
[email protected]
https://www.ietf.org/mailman/listinfo/avt


_______________________________________________
Audio/Video Transport Core Maintenance
[email protected]
https://www.ietf.org/mailman/listinfo/avt