From: "Brandenburg, R. (Ray) van" <ray.vanbrandenburg@tno.nl>
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
Thread-Topic: Gen-ART review of draft-ietf-avtcore-idms-09
Thread-Index: Ac5k5mDClosY2XEXSFmBhpnaPpC1lwAw3NGAAAWr/5AAA+nLUAAASPBwAAJBThAAAsYU4A==
Date: Mon, 10 Jun 2013 14:27:05 +0000
Message-ID: <FCC100FC8D6B034CB88CD8173B2DA1581F34D281@EXC-MBX03.tsn.tno.nl>
References: <9904FB1B0159DA42B0B887B7FA8119CA19894C@AZ-FFEXMB04.global.avaya.com>
 <FCC100FC8D6B034CB88CD8173B2DA1581F34C609@EXC-MBX03.tsn.tno.nl>
 <9904FB1B0159DA42B0B887B7FA8119CA199C1B@AZ-FFEXMB04.global.avaya.com>
 <FCC100FC8D6B034CB88CD8173B2DA1581F34CC74@EXC-MBX03.tsn.tno.nl>
 <FCC100FC8D6B034CB88CD8173B2DA1581F34CDCD@EXC-MBX03.tsn.tno.nl>
 <9904FB1B0159DA42B0B887B7FA8119CA199D6F@AZ-FFEXMB04.global.avaya.com>
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA199D6F@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
Cc: General Area Review Team <gen-art@ietf.org>, "avt@ietf.org" <avt@ietf.org>,
 "draft-ietf-avtcore-idms.all@tools.ietf.org"
 <draft-ietf-avtcore-idms.all@tools.ietf.org>
Subject: Re: [AVTCORE] Gen-ART review of draft-ietf-avtcore-idms-09
Precedence: list

Hi Dan,

Please see inline. We seem to be converging:)

Ray



-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20
Sent: maandag 10 juni 2013 15:11
To: Brandenburg, R. (Ray) van
Cc: avt@ietf.org; General Area Review Team; Roni Even (ron.even.tlv@gmail.c=
om); draft-ietf-avtcore-idms.all@tools.ietf.org
Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09

Hi Ray,

Thanks again for considering my comments.=20

See in-line.=20

Regards,

Dan




> -----Original Message-----
> From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl]
> Sent: Monday, June 10, 2013 3:28 PM
> To: Romascanu, Dan (Dan)
> Cc: avt@ietf.org; General Area Review Team; Roni Even=20
> (ron.even.tlv@gmail.com); draft-ietf-avtcore-idms.all@tools.ietf.org
> Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09
>=20
> Hi Dan,
>=20
> (I've cc'ed the AVTCORE list on Magnus' request)
>=20
> Please see my comments inline (I've shortened the message exchange=20
> somewhat to only include the points of discussion).
>=20
> Best regards,
>=20
> Ray
>=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=20
> > the ETSI document, referencing it where necessary and including=20
> > sections that describe this relationship. In the end, the WG=20
> > consensus was that the IETF draft should be the normative spec for=20
> > the XR block and AVTCORE should have full change control over it. We=20
> > therefore removed most references to the ETSI spec, and instead=20
> > started a Work Item in ETSI to change TS 183 063 to point to the=20
> > IETF draft and remove all normative statements (apart from extending=20
> > the IETF-defined block with three new SPST values).
> >
> [[DR]] Thank you for the clarification information. This is very useful.
> Can you tell what is the status of the work item in ETSI?
>=20
> [Ray] The current status is that the Work Item has been opened and the=20
> contributions have been written and discussed. ETSI has postponed=20
> formally accepting the contributions until the IETF document is given=20
> an RFC number so that they can reference it.
>=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=20
> > there is no need to describe this relationship in the IETF draft.=20
> > The IETF spec is the normative 'base' spec, and ETSI is just=20
> > describing a way to use it within an IPTV system, including three=20
> > additional SPST values specific to that scenario.
> [[DR]] I disagree that there is no need to describe this relationship=20
> on the IETF draft. As control for the XR block was previously in ETSI=20
> and will now be transferred to the IETF we should assume that there=20
> are implementers and deployments who know about the older ETSI=20
> specification. You need a sections that describes the relationship=20
> with the ETSI document, and describes the changes relative to that=20
> version - same as would have been written if there was an RFC that was=20
> updated or made obsolete by this document.
>=20
> Moreover, the current document is not consistent, as it still keeps a=20
> normative reference to the older (not even the latest version) ETSI=20
> document. This will be not needed any longer, an informational=20
> reference would be sufficient.
>=20
> [Ray] I agree completely. This seems to be a relic and I will update=20
> the reference to make it informational.
>=20
> > 1. This document is tightly connected with the ETSI specification TS
> > 183 063. However this relation is mentioned only in a couple of=20
> > places and does not describe the complexity of the relation.=20
> > Moreover, the relation itself seems problematic.
> >
> > The I-D uses some of the inter-destination media techniques=20
> > described by ETSI TS 183 063. For example Section 7 replicates part=20
> > of the content of Annex W of the ETSI document. It does it partially=20
> > however, and with some modifications, as only the content definition=20
> > and behavior of the transmitters and receivers for SPST=3D1 were taken=
=20
> > from Annex W, while the content and behavior for SPST=3D2-4 are marked=
=20
> > as 'defined by ETSI TISPAN'. The ETSI document details what happens=20
> > with the fields when SPST=3D2-4. This will result in the RTCP XR block=
=20
> > for IDMS to be defined in two places - part in this IETF document=20
> > (if approved), the rest in the ETSI document (to be modified=20
> > accordingly in the future). For some period of time the same fields=20
> > will be defined in two places. This seems broken.
> >
> > [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]
> >
> [[DR]] Eventually it will solve the issue, but the situation is murky=20
> in the interim. I believe that creating a registry would be good,=20
> because it provides a way to describe the interim situation, and also=20
> because we do not know yet for sure who may use the values 5-15 in the fu=
ture.
>=20
> [Ray] As Roni mentioned, it is a chicken-egg problem. If there is=20
> consensus in the WG to create a registry, I am happy to include one in=20
> the draft.
>=20
> > 2. The note to the RFC Editor in section 14.2 states:
> >
> >    14.2.  RTCP XR IDMS Report Block
> >
> >    This document assigns the block type value 12 in the IANA "RTCP XR
> >    Block Type Registry" to the RTCP XR IDMS Report Block.
> >
> >    [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.
> >
> > The first statement is not accurate. Value 12 is not a new=20
> > 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=20
> > IDMS information to the IETF defined RTCP XR IDMS Report Block.
> >
> > [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,=20
> > right?]
> >
> [[DR]] The phrase 'This document assigns ... ' is typically used for=20
> new assignments, and may be misleading, especially in the interim.
> Describing explicitly the transfer of control is better IMO.
>=20
> [Ray] Fair enough. How about: 'This document asks to update the=20
> assignment of value 12 from the RTCP XR Block Type for reporting IDMS=20
> information to the RTCP XR IDMS Report Block defined in this document' ?
>=20
[[DR]] close, with slight edits, I would make it:=20

'This document updates the assignment of value 12 from the RTCP XR Block Ty=
pe for reporting IDMS information as per [TS183063] to the RTCP XR IDMS Rep=
ort Block defined in this document'=20

[Ray] Ok.


> > This change is however partial as described previously, as the=20
> > content of the fields and behavior for SPST =3D 2-4 remain under ETSI c=
ontrol.
> > 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=20
> > registry and the policy for adding and approving new values for SPST.
> >
> > This solution is not clean. Only one organization should have=20
> > control upon the definition of one single RTCP XR block type. Either=20
> > the IETF should make the overleaping parts of the  document=20
> > Informational and reflect the content of the ETSI document, or=20
> > should take control over the whole block.
> >
> > [Ray: See my earlier comments: IETF will have full control, ETSI=20
> > will just be extending it.]
> >
> [[DR]] a registry is better, it also avoids the need to make changes=20
> to this document if new extensions are being defined by ETSI or other=20
> organizations.
>=20
> [Ray] See my earlier comment: if the WG consensus is that we need a=20
> registry, I can include one.
>=20
> > 3. The relation with the ETSI specification TS 183 063 should have=20
> > been described clearly from the beginning of the document.
> >
> > [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].
> >
> [[DR]] This is where we disagree. If there was no history of control,=20
> no previous ETSI specification you would be right, but this is not the=20
> case.
>=20
> [Ray] Can we agree to a short informational section that describes the=20
> history of IDMS in ETSI and IETF?
>=20
>=20
[[DR]] that's all I am asking

[Ray] Ok, I think that is acceptable.=20

> > 4. In Section 7:
> >
> >    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.
> >
> > Why a SHOULD here and not a MUST? If there are any cases of=20
> > exception they need to be detailed.
> >
> > [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]
> >
> [[DR]] It would be good to clarify this in the text.
>=20
> [Ray] OK
>=20
>=20
> > 7. In Section 8:
> >
> >    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.
> >
> > Why a MAY here? Especially for the case when none of the receivers=20
> > reported, what content can be set there but 0 ?
> >
> > [Ray: I believe it should be up to the implementation to decide how=20
> > it wants to handle the case of there being only one receiver who=20
> > reported on presentation timestamps].
> >
> [[DR]] OK, so the cases when none of the receivers reported and one=20
> receiver only reported should be dealt with differently. This needs to=20
> be clarified.
>=20
> [Ray] What exactly is the problem with the MAY here? IMO it doesn't=20
> create any interop issues: whatever is the reason for setting the=20
> value to 0, to the client the end result is the same: ignore it.
>=20

[[DR]] In the case when none of the receivers reported we want to avoid lea=
ving some garbage in this field which could be interpreted differently - do=
n't we?=20

[Ray] I think I see where we disagree. The paragraph says: "If this field i=
s 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". The way I =
read this is as: In the case the field is declared empty (=3D contains NULL=
 information), it SHALL be set to 0. There can be different reasons for dec=
laring the field empty/NULL, one of those reasons is if none or only one re=
ceiver reported on presentation timestamps. To me, the paragraph doesn't sa=
y that this is the only possible reason, but it does specify very clearly t=
hat if you decide the field should be empty, you SHALL set it to zero.=20


> Best regards,
>=20
> Ray
> This e-mail and its contents are subject to the DISCLAIMER at=20
> http://www.tno.nl/emaildisclaimer