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

["Brandenburg, R. (Ray) van" <[e-mail]>]

Hi WG, 

Below you will find the Gen-ART review of the IDMS draft, including my response to it.

Since some of the comments in the review have to do with the relationship with the ETSI spec, a topic which we have discussed in the WG earlier, I'm copying the WG here. 

Best regards,

Ray

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[e-mail]] 
Sent: maandag 10 juni 2013 12:22
To: Brandenburg, R. (Ray) van; General Area Review Team
Cc: [e-mail]; Roni Even ([e-mail])
Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09

Hi Ray,

Thank you for the detailed answer. 

See in-line. 

Regards,

Dan




> -----Original Message-----
> From: Brandenburg, R. (Ray) van [mailto:[e-mail]]
> Sent: Monday, June 10, 2013 11:33 AM
> To: Romascanu, Dan (Dan); General Area Review Team
> Cc: [e-mail]; Roni Even
> ([e-mail])
> Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09
> 
> Hi Dan,
> 
> Many thanks for your very thorough review.
> 
> 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? 

> 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.  

> 
> Personally, I agree with the WG consensus that this is the 'cleanest'
> way to handle it, resulting in backwards compatibility with older 
> versions of the ETSI document as well as have full change control in 
> IETF.
> 
> Please see inline for your comments.
> 
> Best regards,
> 
> Ray
> 
> 
> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[e-mail]]
> Sent: zondag 9 juni 2013 9:53
> To: General Area Review Team
> Cc: [e-mail]
> Subject: Gen-ART review of draft-ietf-avtcore-idms-09
> 
> (resending, I mis-spelled .all address at the first try)
> 
> I am the assigned Gen-ART reviewer for this draft. For background on 
> Gen-ART, please see the FAQ at
> 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please resolve these comments along with any other Last Call comments 
> you may receive.
> 
> Document: draft-ietf-avtcore-idms-09
> Reviewer: Dan Romascanu
> Review Date: 6/6/13
> IETF LC End Date: 6/11/13
> IESG Telechat date:
> 
> Summary:
> 
> Not Ready
> 
> Major issues:
> 
> 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. 

> 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. 

> 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. 

> 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. 

> Minor issues:
> 
> 1. The version of the block definition is set to V=2 which is the same 
> as in the ETSI specification. Were versions 0 and 1 already used by 
> ETSI? If this is the case a note should be made.
> 
> [Ray: This part of the header is defined by RFC3611, and is specified 
> to be set to 2 to refer to the version of RTP]
> 
[[DR]] OK

> 2. In Section 7:
> 
>    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.
> 
> s/MUST be set to zero/MUST be set to zero at transmission/
> 
> [Ray: Thanks, I will update the draft]
> 
> 3. In Section 7:
> 
>    Reserved bits (Resrv): 25 bits.  These bits are reserved for future
>    use and SHALL be set to 0.
> 
> s/ SHALL be set to 0/ MUST be set to zero at transmission and MUST be 
> ignored by the receiver/
> 
> [Ray: Thanks, I will update the draft]
> 
> 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. 

> 5. In Section 8:
> 
>    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.
> 
> Why a SHOULD here and not a MUST? If there are any cases of exception 
> they need to be detailed.
> 
> [Ray: I will check with my co-authors]
> 
> 6. In Section 8:
> 
>    This SHOULD relate to the first
>    arriving RTP packet containing this particular RTP timestamp, in case
>    multiple RTP packets contain the same RTP timestamp.
> 
> Why a SHOULD here and not a MUST? If there are any cases of exception 
> they need to be detailed.
> 
> [Ray: I will check with my co-authors]
> 
> 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. 

> 8: The reference:
> 
> [TS183063]
>               "IMS-based IPTV stage 3 specification, TS 183 063 v3.4.1",
>               June 2010.
> 
> V3.4.1 is not the latest release. Is this intentional? I found at 
> least one more recent release dated 2011 and numbered 3.5.2 - I do not 
> know if there is any diff in the relevant content, but pointing to the 
> most updated review seems appropriate.
> 
> [Ray: Thanks for noticing, I will update the reference to the latest 
> ETSI release].
> 
> 9: Did this document undergo an SDP directorate review? If not I 
> believe that one would be necessary, as a new SDP Attribute is being defined.
> 
> [Ray: Yes, an SDP directorate review has been carried out].
> 
> Nits/editorial comments:
> 
> 1. typo in the last paragraph of section 5 - s/nessecary/necessary/
> 
> 2. in section 8 expand PT as Packet Type
> 
> 3. typo in the first paragraph of section 11 - s/mutli/multi/
> 
> [Ray: Thanks, I will update the draft]
> 
> Regards,
> 
> Dan
> 
> [Ray: Again, many thanks for the thorough review!]
> 
> 
> 
> This e-mail and its contents are subject to the DISCLAIMER at 
> http://www.tno.nl/emaildisclaimer