From: "Brandenburg, R. (Ray) van" <ray.vanbrandenburg@tno.nl>
To: "avt@ietf.org" <avt@ietf.org>
Thread-Topic: Gen-ART review of draft-ietf-avtcore-idms-09
Thread-Index: Ac5k5mDClosY2XEXSFmBhpnaPpC1lwAw3NGAAAWr/5AAA+nLUA==
Date: Mon, 10 Jun 2013 11:49:46 +0000
Message-ID: <FCC100FC8D6B034CB88CD8173B2DA1581F34CC74@EXC-MBX03.tsn.tno.nl>
References: <9904FB1B0159DA42B0B887B7FA8119CA19894C@AZ-FFEXMB04.global.avaya.com>
 <FCC100FC8D6B034CB88CD8173B2DA1581F34C609@EXC-MBX03.tsn.tno.nl>
 <9904FB1B0159DA42B0B887B7FA8119CA199C1B@AZ-FFEXMB04.global.avaya.com>
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA199C1B@AZ-FFEXMB04.global.avaya.com>
Accept-Language: en-US, nl-NL
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [AVTCORE] FW: Gen-ART review of draft-ietf-avtcore-idms-09
Precedence: list

Hi WG,=20

Below you will find the Gen-ART review of the IDMS draft, including my resp=
onse to it.

Since some of the comments in the review have to do with the relationship w=
ith the ETSI spec, a topic which we have discussed in the WG earlier, I'm c=
opying the WG here.=20

Best regards,

Ray

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20
Sent: maandag 10 juni 2013 12:22
To: Brandenburg, R. (Ray) van; General Area Review Team
Cc: draft-ietf-avtcore-idms.all@tools.ietf.org; Roni Even (ron.even.tlv@gma=
il.com)
Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09

Hi Ray,

Thank you for the detailed answer.=20

See in-line.=20

Regards,

Dan




> -----Original Message-----
> From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl]
> Sent: Monday, June 10, 2013 11:33 AM
> To: Romascanu, Dan (Dan); General Area Review Team
> Cc: draft-ietf-avtcore-idms.all@tools.ietf.org; Roni Even
> (ron.even.tlv@gmail.com)
> Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09
>=20
> Hi Dan,
>=20
> Many thanks for your very thorough review.
>=20
> Before responding to your comments in detail, let me give you some=20
> background on how we handle the relationship with the ETSI document:
> Exactly how we should deal with the existing ETSI spec has been=20
> discussed at length in AVTCORE, both on- and offlist. As you can see=20
> in the earlier versions of the draft, the document used to extend the=20
> ETSI document, referencing it where necessary and including sections=20
> that describe this relationship. In the end, the WG consensus was that=20
> the IETF draft should be the normative spec for the XR block and=20
> AVTCORE should have full change control over it. We therefore removed=20
> most references to the ETSI spec, and instead started a Work Item in=20
> ETSI to change TS 183 063 to point to the IETF draft and remove all=20
> normative statements (apart from extending the IETF-defined block with=20
> three new SPST values).
>=20
[[DR]] Thank you for the clarification information. This is very useful. Ca=
n you tell what is the status of the work item in ETSI?=20

> The current idea is therefore that since the ETSI spec will be=20
> referencing the IETF spec, instead of the other way around, that there=20
> is no need to describe this relationship in the IETF draft. The IETF=20
> spec is the normative 'base' spec, and ETSI is just describing a way=20
> to use it within an IPTV system, including three additional SPST=20
> values specific to that scenario.
[[DR]] I disagree that there is no need to describe this relationship on th=
e IETF draft. As control for the XR block was previously in ETSI and will n=
ow be transferred to the IETF we should assume that there are implementers =
and deployments who know about the older ETSI specification. You need a sec=
tions that describes the relationship with the ETSI document, and describes=
 the changes relative to that version - same as would have been written if =
there was an RFC that was updated or made obsolete by this document.=20

Moreover, the current document is not consistent, as it still keeps a norma=
tive reference to the older (not even the latest version) ETSI document. Th=
is will be not needed any longer, an informational reference would be suffi=
cient. =20

>=20
> Personally, I agree with the WG consensus that this is the 'cleanest'
> way to handle it, resulting in backwards compatibility with older=20
> versions of the ETSI document as well as have full change control in=20
> IETF.
>=20
> Please see inline for your comments.
>=20
> Best regards,
>=20
> Ray
>=20
>=20
> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
> Sent: zondag 9 juni 2013 9:53
> To: General Area Review Team
> Cc: draft-ietf-avtcore-idms.all@tools.ietf.org
> Subject: Gen-ART review of draft-ietf-avtcore-idms-09
>=20
> (resending, I mis-spelled .all address at the first try)
>=20
> I am the assigned Gen-ART reviewer for this draft. For background on=20
> Gen-ART, please see the FAQ at
>=20
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>=20
> Please resolve these comments along with any other Last Call comments=20
> you may receive.
>=20
> Document: draft-ietf-avtcore-idms-09
> Reviewer: Dan Romascanu
> Review Date: 6/6/13
> IETF LC End Date: 6/11/13
> IESG Telechat date:
>=20
> Summary:
>=20
> Not Ready
>=20
> Major issues:
>=20
> 1. This document is tightly connected with the ETSI specification TS=20
> 183 063. However this relation is mentioned only in a couple of places=20
> and does not describe the complexity of the relation. Moreover, the=20
> relation itself seems problematic.
>=20
> The I-D uses some of the inter-destination media techniques described=20
> by ETSI TS 183 063. For example Section 7 replicates part of the=20
> content of Annex W of the ETSI document. It does it partially however,=20
> and with some modifications, as only the content definition and=20
> behavior of the transmitters and receivers for SPST=3D1 were taken from=20
> Annex W, while the content and behavior for SPST=3D2-4 are marked as=20
> 'defined by ETSI TISPAN'. The ETSI document details what happens with=20
> the fields when SPST=3D2-4. This will result in the RTCP XR block for=20
> IDMS to be defined in two places - part in this IETF document (if=20
> approved), the rest in the ETSI document (to be modified accordingly=20
> in the future). For some period of time the same fields will be=20
> defined in two places. This seems broken.
>=20
> [Ray: See my comments above. The ETSI document will be changed to=20
> point to the IETF spec. Does this solve your issue? In addition, we=20
> could create an IANA registry for SPST values, although I personally=20
> believe this to not be necessary]
>=20
[[DR]] Eventually it will solve the issue, but the situation is murky in th=
e interim. I believe that creating a registry would be good, because it pro=
vides a way to describe the interim situation, and also because we do not k=
now yet for sure who may use the values 5-15 in the future.=20

> 2. The note to the RFC Editor in section 14.2 states:
>=20
>    14.2.  RTCP XR IDMS Report Block
>=20
>    This document assigns the block type value 12 in the IANA "RTCP XR
>    Block Type Registry" to the RTCP XR IDMS Report Block.
>=20
>    [Note to RFC Editor: this block type value is currently assigned to
>    [TS183063].  This document replaces [TS183063] as the normative
>    specification of the RTCP XR IDMS Report Block.  Upon publication of
>    this document as RFC, [TS183063] will be changed to reflect this.
>=20
> The first statement is not accurate. Value 12 is not a new assignment,
> 12 was already assigned by ETSI, this document asks to change the=20
> assignment of value 12 from the RTCP XR Block Type for reporting IDMS=20
> information to the IETF defined RTCP XR IDMS Report Block.
>=20
> [Ray: Hmm, I'm not sure. I checked with IANA and they don't see a=20
> problem in the current wording. I think this is fundamentally a=20
> question of describing the 'soll' situation versus describing the=20
> process of getting from 'ist' to 'soll'. Once the ETSI doc has been=20
> updated, your proposed sentence  would no longer be necessary, right?]
>=20
[[DR]] The phrase 'This document assigns ... ' is typically used for new as=
signments, and may be misleading, especially in the interim. Describing exp=
licitly the transfer of control is better IMO.=20

> This change is however partial as described previously, as the content=20
> of the fields and behavior for SPST =3D 2-4 remain under ETSI control.
> Moreover, it is not clear who has further control for other new=20
> values, as SPST =3D 5-15 show as 'reserved for future use in both=20
> documents'. The IANA section does not define or refer an IANA registry=20
> and the policy for adding and approving new values for SPST.
>=20
> This solution is not clean. Only one organization should have control=20
> upon the definition of one single RTCP XR block type. Either the IETF=20
> should make the overleaping parts of the  document Informational and=20
> reflect the content of the ETSI document, or should take control over=20
> the whole block.
>=20
> [Ray: See my earlier comments: IETF will have full control, ETSI will=20
> just be extending it.]
>=20
[[DR]] a registry is better, it also avoids the need to make changes to thi=
s document if new extensions are being defined by ETSI or other organizatio=
ns.=20

> 3. The relation with the ETSI specification TS 183 063 should have=20
> been described clearly from the beginning of the document.
>=20
> [Ray: See my earlier comment. Since the IETF draft will be that=20
> normative spec that ETSI will be referencing, I believe this=20
> relationship should be described in ETSI, not in IETF].
>=20
[[DR]] This is where we disagree. If there was no history of control, no pr=
evious ETSI specification you would be right, but this is not the case.=20

> Minor issues:
>=20
> 1. The version of the block definition is set to V=3D2 which is the same=
=20
> as in the ETSI specification. Were versions 0 and 1 already used by=20
> ETSI? If this is the case a note should be made.
>=20
> [Ray: This part of the header is defined by RFC3611, and is specified=20
> to be set to 2 to refer to the version of RTP]
>=20
[[DR]] OK

> 2. In Section 7:
>=20
>    Reserved bits (Resrv): 3 bits.  These bits are reserved for future
>    definition.  In the absence of such a definition, the bits in this
>    field MUST be set to zero and MUST be ignored by the receiver.
>=20
> s/MUST be set to zero/MUST be set to zero at transmission/
>=20
> [Ray: Thanks, I will update the draft]
>=20
> 3. In Section 7:
>=20
>    Reserved bits (Resrv): 25 bits.  These bits are reserved for future
>    use and SHALL be set to 0.
>=20
> s/ SHALL be set to 0/ MUST be set to zero at transmission and MUST be=20
> ignored by the receiver/
>=20
> [Ray: Thanks, I will update the draft]
>=20
> 4. In Section 7:
>=20
>    When
>    reporting on an RTP packet which is one of several consecutive RTP
>    packets having equal timestamps, an SC SHOULD report on the RTP
>    packet it received with the lowest sequence number.
>=20
> Why a SHOULD here and not a MUST? If there are any cases of exception=20
> they need to be detailed.
>=20
> [Ray: Implementations might be optimized for specific scenarios by=20
> reporting on specific packets as indicated by e.g. an out-of-band=20
> signal]
>=20
[[DR]] It would be good to clarify this in the text.=20

> 5. In Section 8:
>=20
>    Because RTP
>    timestamps do wrap around, the sender of this packet SHOULD use
>    recent values, i.e. choose NTP timestamps that reflect current time
>    and not too far in the future or in the past.
>=20
> Why a SHOULD here and not a MUST? If there are any cases of exception=20
> they need to be detailed.
>=20
> [Ray: I will check with my co-authors]
>=20
> 6. In Section 8:
>=20
>    This SHOULD relate to the first
>    arriving RTP packet containing this particular RTP timestamp, in case
>    multiple RTP packets contain the same RTP timestamp.
>=20
> Why a SHOULD here and not a MUST? If there are any cases of exception=20
> they need to be detailed.
>=20
> [Ray: I will check with my co-authors]
>=20
> 7. In Section 8:
>=20
>    The timestamp is formatted based on the NTP
>    timestamp format as specified in [RFC5905].  If this field is empty,
>    then it SHALL be set to 0.  This field MAY be left empty if none or
>    only one of the receivers reported on presentation timestamps.
>=20
> Why a MAY here? Especially for the case when none of the receivers=20
> reported, what content can be set there but 0 ?
>=20
> [Ray: I believe it should be up to the implementation to decide how it=20
> wants to handle the case of there being only one receiver who reported=20
> on presentation timestamps].
>=20
[[DR]] OK, so the cases when none of the receivers reported and one receive=
r only reported should be dealt with differently. This needs to be clarifie=
d.=20

> 8: The reference:
>=20
> [TS183063]
>               "IMS-based IPTV stage 3 specification, TS 183 063 v3.4.1",
>               June 2010.
>=20
> V3.4.1 is not the latest release. Is this intentional? I found at=20
> least one more recent release dated 2011 and numbered 3.5.2 - I do not=20
> know if there is any diff in the relevant content, but pointing to the=20
> most updated review seems appropriate.
>=20
> [Ray: Thanks for noticing, I will update the reference to the latest=20
> ETSI release].
>=20
> 9: Did this document undergo an SDP directorate review? If not I=20
> believe that one would be necessary, as a new SDP Attribute is being defi=
ned.
>=20
> [Ray: Yes, an SDP directorate review has been carried out].
>=20
> Nits/editorial comments:
>=20
> 1. typo in the last paragraph of section 5 - s/nessecary/necessary/
>=20
> 2. in section 8 expand PT as Packet Type
>=20
> 3. typo in the first paragraph of section 11 - s/mutli/multi/
>=20
> [Ray: Thanks, I will update the draft]
>=20
> Regards,
>=20
> Dan
>=20
> [Ray: Again, many thanks for the thorough review!]
>=20
>=20
>=20
> This e-mail and its contents are subject to the DISCLAIMER at=20
> http://www.tno.nl/emaildisclaimer