Subject: Re: opsdir review of draft-ietf-ipdvb-ule-ext-07] - Proposed changes.

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 13 Mar 2008 13:26:19 -0400

A late OPSDIR review flagged some places where the guidance could be 
tightened (a few paragraphs of rewording and one minor change to the 
spec - require padding of unused  low-order time stamp bits with zero's 
in section 3.3).

I've spoken to Bernhard (co-author) and Martin (as Shepherd) and we
think two changes are appropriate. If anyone on this list has concerns 
about the proposed changes please *DO* tell us. All issues need to be 
received by Thursday 20th March 2008.

Best wishes,

Gorry Fairhurst
(as WG Chair)

----------- Proposed Change note ----------

Section 3.1:

OLD:
  "This document does not specify how TS Packets are to be
  handled at the Receiver, however it notes that a poorly
  configured Encapsulator could lead to a Multiplex carrying
  multiple (possibly conflicting) sets of TS Logical Channels
  and SI information encapsulated at different levels or with
  different NPA addresses. The need for  consistency in the use
  of PIDs and the related SI information is described in
  section 4.2 of [RFC4947]."

NEW:
  "This document does not specify how TS Packets are to be
  handled at the Receiver. However, it notes:

  * A Receiver needs to consistently associate all TS Packets
  in a Stream with one TS Logical Channel (Stream). If an
  Encapsulator transmits more than one Stream of TS Packets
  each encapsulated at a different level or with a different
  NPA address, a Receiver needs to ensure that each is
  independently demultiplexed as a separate Stream (Section 3.2
  [RFC4259]).

  * If an Encapsulator transmits service information
  encapsulated at different levels or with different NPA
  addresses, the Receivers need to ensure each Stream is related
  to the corresponding SI table information (if any). A
  RECOMMENDED  way to reduce signaling interactions is to ensure
  each PID value uniquely identifies a Stream within a TS
  Multiplex carrying ULE and also any TS Packets encapsulated
  by a ULE/GSE Stream.

  The need for consistency in the use of PIDs and the related
  service information is described in section 4.2 of [RFC4947]."

---
In Section 3.3

OLD:
  "may use an arbitrary (and varying) value to pad the unused
  least-significant bits."

NEW:
  "MUST pad the unused least-significant bits with a value of zero."

--- end of change note

--------------------------------

The following text contains the detailed comments and responses
from the authors. This is provided for information and
completeness since the document has already been approved for
publication.

> David Harrington wrote:
> > I have reviewed this document as part of the operations 
> directorate's 
> > ongoing effort to review IETF documents being submitted to 
> the IESG.  
> > These comments were written primarily for the benefit of 
> the OPS area 
> > directors.  Document editors and WG chairs should treat 
> these comments 
> > just like any other last call comments.
> > 
> > draft-ietf-ipdvb-ule-ext defines multiple extensions for 
> ULE and GSE 
> > encapsulations of IPDVB traffic.
> > 
> > This is an area in which I have no expertise.
> > 
> Your comments are still appreciated!
> 
> > I have a few concerns about the document. 
> ---------------------------------------------------------------
> > In section 3.1, there is a paragraph that mentions the need to 
> > update/modify the timing information, and says "these 
> issues are not 
> > considered here". That makes me concerned that they may not be 
> > considered anywhere.
> > 
> These issues are expected to be addressed in the Guidelines 
> to GSE, to be published as an ETSI Technical Report 
> (equivalent to an IETF INFO RFC). It is normal to start a 
> Guidelines TR, once operational experience has been obtained 
> from implementation. Clock references impact the physical 
> layer and native video (rather than IP). Our thoughts were 
> that DVB-specific details should be handled by DVB via ETSI.
>
> - We think no change needed.
> ---------------------------------------------------------------
> > section 3.1 also "notes that a poorly configured Encapsulator could 
> > lead to a Multiplex carrying multiple (possibly 
> conflicting) sets of 
> > TS Logical Channels ..." I am not sure that the pointer to 
> [RFC4947] 
> > adequately addresses the issue.
> > 
> I'd be happy for it to say more, but as I see it the whole of 
> the TS Multiplex transmission network requires consistent 
> configuration, and this adds just one more thing that needs 
> to be done consistently. I think it is hard to be 
> perscriptive here, given the wide range of networks that use 
> this technology. Is the following better?
>
> - Suggested change.
> ---------------------------------------------------------------
> > In section 3.2, the Packing Threshold SHOULD be configurable in the 
> > Encapsulator. I wonder why this is not a MUST be configurable?
> > 
> This follows the practice RFC 4236 for the ULE Packing 
> Threshold. This was deemed a "SHOULD" since it does not 
> impact interoperability between the sender and receiver (all 
> values result in "correct" operation - the value is a 
> performance-tuning parameter that operators will likely wish 
> to use to control Jitter and efficiency).
>
> - We think no change is needed.
> ---------------------------------------------------------------
> > In section 3.3, "Systems unable to insert timestamps at the 
> specified 
> > resolution may use an arbitrary (and varying) value to pad 
> the unused 
> > least-significant bits." I wonder why this isn't simply padded with 
> > 0-bits. Is there a reason why the padding is arbitrary and varying?
> > 
> Thanks! The reason is that some people suggested use of the 
> TimeStamp for also transferring a reference clock (inspired 
> by RFC4340). I think we reached consensus that this was not 
> the primary function, and therefore it is better if the 
> TimeStamp value ONLY increased.
> We agree with your proposed correction.
>
> - Suggested change.
> ---------------------------------------------------------------
> > section 3.3 also says "Receivers MAY process the timestamp when the 
> > PDU encapsulation is removed. Recievers that do not 
> implement, or do 
> > not wish to process, the TimeStamp Extsnsion MAY skip this 
> extension 
> > header." I always get concerned when a "standard" is allowed to be 
> > ignored at the implemeter's whim, and such behavior still 
> somehow gets 
> > classified as being standard-compliant. Either they should 
> be required 
> > to process the fields, or they should not be allowed to declare 
> > compliance to the standard.
> > 
> - We do not intend to obsolete/update RFC4326 as deployed.
> We could say "Receivers SHOULD process", but then we'd still 
> need to allow RFC4326 Receivers to ignore this unknown extension.
> - We thing this is correct.
> ---------------------------------------------------------------
> > Idnits complains about the [GSE] normative reference, which 
> is an ETSI 
> > document, and about the reference to sec-req-04 being outdated.
> > 
> Correct, draft-ietf-ipdvb-sec-req was revised to rev -05.
> - This could be corrected next rev.
> The ETSI GSE Technical Specification (TS) is indeed a 
> normative reference on the framing structure, and this TS 
> cites this document as Normative too on the extension format.
> - This seems correct to us, no change needed.
> ---------------------------------------------------------------
> > It is recommended practice to place the Intellectual property 
> > statement at the end of the file. This document places the Appendix 
> > after the Intellectual property statement.
> > 
> - Noted, this will be corrected.
> ---------------------------------------------------------------
> > 
> > David Harrington
> > [email-masked]
> > [email-masked]
>