Re: [AVTCORE] Gen-ART review of draft-ietf-avtcore-idms-09

["Romascanu, Dan (Dan)" <[e-mail]>]

Hi Ray,

Thanks again for considering my comments. 

See in-line. 

Regards,

Dan




> -----Original Message-----
> From: Brandenburg, R. (Ray) van [mailto:[e-mail]]
> Sent: Monday, June 10, 2013 3:28 PM
> To: Romascanu, Dan (Dan)
> Cc: [e-mail]; General Area Review Team; Roni Even
> ([e-mail]); [e-mail]
> Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09
> 
> Hi Dan,
> 
> (I've cc'ed the AVTCORE list on Magnus' request)
> 
> Please see my comments inline (I've shortened the message exchange
> somewhat to only include the points of discussion).
> 
> Best regards,
> 
> Ray
> 
> > Before responding to your comments in detail, let me give you some
> > background on how we handle the relationship with the ETSI document:
> > Exactly how we should deal with the existing ETSI spec has been
> > discussed at length in AVTCORE, both on- and offlist. As you can see
> > in the earlier versions of the draft, the document used to extend the
> > ETSI document, referencing it where necessary and including sections
> > that describe this relationship. In the end, the WG consensus was that
> > the IETF draft should be the normative spec for the XR block and
> > AVTCORE should have full change control over it. We therefore removed
> > most references to the ETSI spec, and instead started a Work Item in
> > ETSI to change TS 183 063 to point to the IETF draft and remove all
> > normative statements (apart from extending 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?
> 
> [Ray] The current status is that the Work Item has been opened and the
> contributions have been written and discussed. ETSI has postponed
> formally accepting the contributions until the IETF document is given an
> RFC number so that they can reference it.
> 
> > The current idea is therefore that since the ETSI spec will be
> > referencing the IETF spec, instead of the other way around, that there
> > is no need to describe this relationship in the IETF draft. The IETF
> > spec is the normative 'base' spec, and ETSI is just describing a way
> > to use it within an IPTV system, including three additional SPST
> > values specific to that scenario.
> [[DR]] I disagree that there is no need to describe this relationship on
> the IETF draft. As control for the XR block was previously in ETSI and
> will now be transferred to the IETF we should assume that there are
> implementers and deployments who know about the older ETSI
> specification. You need a sections 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.
> 
> Moreover, the current document is not consistent, as it still keeps a
> normative reference to the older (not even the latest version) ETSI
> document. This will be not needed any longer, an informational reference
> would be sufficient.
> 
> [Ray] I agree completely. This seems to be a relic and I will update the
> reference to make it informational.
> 
> > 1. This document is tightly connected with the ETSI specification TS
> > 183 063. However this relation is mentioned only in a couple of places
> > and does not describe the complexity of the relation. Moreover, the
> > relation itself seems problematic.
> >
> > The I-D uses some of the inter-destination media techniques described
> > by ETSI TS 183 063. For example Section 7 replicates part of the
> > content of Annex W of the ETSI document. It does it partially however,
> > and with some modifications, as only the content definition and
> > behavior of the transmitters and receivers for SPST=1 were taken from
> > Annex W, while the content and behavior for SPST=2-4 are marked as
> > 'defined by ETSI TISPAN'. The ETSI document details what happens with
> > the fields when SPST=2-4. This will result in the RTCP XR block for
> > IDMS to be defined in two places - part in this IETF document (if
> > approved), the rest in the ETSI document (to be modified accordingly
> > in the future). For some period of time the same fields will be
> > defined in two places. This seems broken.
> >
> > [Ray: See my comments above. The ETSI document will be changed to
> > point to the IETF spec. Does this solve your issue? In addition, we
> > could create an IANA registry for SPST values, although I personally
> > believe this to not be necessary]
> >
> [[DR]] Eventually it will solve the issue, but the situation is murky in
> the interim. I believe that creating a registry would be good, because
> it provides a way to describe the interim situation, and also because we
> do not know yet for sure who may use the values 5-15 in the future.
> 
> [Ray] As Roni mentioned, it is a chicken-egg problem. If there is
> consensus in the WG to create a registry, I am happy to include one in
> the draft.
> 
> > 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 assignment,
> > 12 was already assigned by ETSI, this document asks to change the
> > assignment of value 12 from the RTCP XR Block Type for reporting 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
> > problem in the current wording. I think this is fundamentally a
> > question of describing the 'soll' situation versus describing the
> > process of getting from 'ist' to 'soll'. Once the ETSI doc has been
> > updated, your proposed sentence  would no longer be necessary, right?]
> >
> [[DR]] The phrase 'This document assigns ... ' is typically used for new
> assignments, and may be misleading, especially in the interim.
> Describing explicitly the transfer of control is better IMO.
> 
> [Ray] Fair enough. How about: 'This document asks to update the
> assignment of value 12 from the RTCP XR Block Type for reporting IDMS
> information to the RTCP XR IDMS Report Block defined in this document' ?
> 
[[DR]] close, with slight edits, I would make it: 

'This document updates the assignment of value 12 from the RTCP XR 
Block Type for reporting IDMS information as per [TS183063] to the 
RTCP XR IDMS Report Block defined in this document' 


> > This change is however partial as described previously, as the content
> > of the fields and behavior for SPST = 2-4 remain under ETSI control.
> > Moreover, it is not clear who has further control for other new
> > values, as SPST = 5-15 show as 'reserved for future use in both
> > documents'. The IANA section does not define or refer an IANA registry
> > and the policy for adding and approving new values for SPST.
> >
> > This solution is not clean. Only one organization should have control
> > upon the definition of one single RTCP XR block type. Either the IETF
> > should make the overleaping parts of the  document Informational and
> > reflect the content of the ETSI document, or should take control over
> > the whole block.
> >
> > [Ray: See my earlier comments: IETF will have full control, ETSI will
> > just be extending it.]
> >
> [[DR]] a registry is better, it also avoids the need to make changes to
> this document if new extensions are being defined by ETSI or other
> organizations.
> 
> [Ray] See my earlier comment: if the WG consensus is that we need a
> registry, I can include one.
> 
> > 3. The relation with the ETSI specification TS 183 063 should have
> > been described clearly from the beginning of the document.
> >
> > [Ray: See my earlier comment. Since the IETF draft will be that
> > normative spec that ETSI will be referencing, I believe this
> > relationship should be described in ETSI, not in IETF].
> >
> [[DR]] This is where we disagree. If there was no history of control, no
> previous ETSI specification you would be right, but this is not the
> case.
> 
> [Ray] Can we agree to a short informational section that describes the
> history of IDMS in ETSI and IETF?
> 
> 
[[DR]] that's all I am asking

> > 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 exception
> > they need to be detailed.
> >
> > [Ray: Implementations might be optimized for specific scenarios by
> > reporting on specific packets as indicated by e.g. an out-of-band
> > signal]
> >
> [[DR]] It would be good to clarify this in the text.
> 
> [Ray] OK
> 
> 
> > 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
> > reported, what content can be set there but 0 ?
> >
> > [Ray: I believe it should be up to the implementation to decide how it
> > wants to handle the case of there being only one receiver who reported
> > on presentation timestamps].
> >
> [[DR]] OK, so the cases when none of the receivers reported and one
> receiver only reported should be dealt with differently. This needs to
> be clarified.
> 
> [Ray] What exactly is the problem with the MAY here? IMO it doesn't
> create any interop issues: whatever is the reason for setting the value
> to 0, to the client the end result is the same: ignore it.
> 

[[DR]] In the case when none of the receivers reported we want to avoid leaving some garbage in this field which could be interpreted differently - don't we? 

> Best regards,
> 
> Ray
> This e-mail and its contents are subject to the DISCLAIMER at
> http://www.tno.nl/emaildisclaimer