[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: opsdir review of draft-ietf-ipdvb-ule-ext-07] - Proposed changes.
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 
> dbharrington@comcast.net
> ietfdbh@comcast.net