Extension Formats for Unidirectional Lightweight Encapsulation (ULE) and the Generic Stream Encapsulation (GSE)
draft-ietf-ipdvb-ule-ext-07

IANA Last Call comments:

[ Note: The actions requested by this document have already been
implemented. The references will be updated upon approval. ]

Action 1:

Upon approval of this document, the IANA will update the
references associated with the following assignments in the
"Unidirectional Lightweight Encapsulation (ULE) Next-Header
Registry - per [RFC4326]" registry located at
http://www.iana.org/assignments/ule-next-headers
sub-registry "Mandatory Extension Headers"

Type Name Reference
------ -------------------------- ---------
2 TS-Concat [RFC-ipdvb-ule-ext-06]
3 PDU-Concat [RFC-ipdvb-ule-ext-06]


Action 2:

Upon approval of this document, the IANA will update the
references associated with the following assignments in the
"Unidirectional Lightweight Encapsulation (ULE) Next-Header
Registry - per [RFC4326]" registry located at
http://www.iana.org/assignments/ule-next-headers
sub-registry "Optional Extension Headers"

Type Name H-LEN Reference
------ -------------------------- ----- ---------
257 Time-Stamp 3 [RFC-ipdvb-ule-ext-06]

We understand the above to be the only IANA Actions for this
document.

PROTO Write-up

1) Have the chairs personally reviewed this version of the ID and do
they believe this ID is sufficiently baked to forward to the IESG for
publication?

Yes.

2) Has the document had adequate review from both key WG members and key
non-WG members? Do you have any concerns about the depth or breadth of
the reviews that have been performed?

Yes. The ID has been discussed and reviewed in the WG as well as with
non-WG members.

3) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

No, as it has already been reviewed by WG and non-WG members that are
expert in this field.

4) Do you have any specific concerns/issues with this document that you
believe the ADs and/or IESG should be aware of? For example, perhaps you
are uncomfortable with certain parts of the document, or whether there
really is a need for it, etc., but at the same time these issues have
been discussed in the WG and the WG has indicated it wishes to advance
the document anyway.

No.

5) How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with others being silent,
or does the WG as a whole understand and agree with it?

There is a solid consensus in the WG supporting this work, at this
point there is no disenting voices about the protocol in the WG.

6) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize what are they upset about.

No.

7) Have the chairs verified that the document adheres to _all_ of the ID
nits? (see http://www.ietf.org/ID-nits.html).

Yes.


8) Does the document a) split references into normative/informative, and
b) are there normative references to IDs, where the IDs are not also
ready for advancement or are otherwise in an unclear state? (Note: the
RFC editor will not publish an RFC with normative references to IDs, it
will delay publication until all such IDs are also ready for publication
as RFCs.)

The document does split references into normative and informative ones.
ID nits is just reporting one down-ref, which actually is not a
down-ref, but a citation of a non-RFC reference:
-- Possible downref: Non-RFC (?) normative reference: ref. 'GSE'

GSE is referring to an ETSI standard document.


9) For Standards Track and BCP documents, the IESG approval announcement
includes a writeup section with the following sections:

- Technical Summary
This document describes a set of Extension Headers for the
Unidirectional Lightweight Encapsulation (ULE), RFC4326. The
Unidirectional Lightweight Encapsulation (ULE) mechanism for the
transport of IPv4 and IPv6 Datagrams
and other network protocol packets directly over the ISO MPEG-2
Transport Stream as TS Private Data. ULE specifies a base
encapsulation format and supports an extension format that allows it
to carry additional header information to assist in network/Receiver
processing.
The Extension Header formats specified in this document define
extensions appropriate to both ULE and the Generic Stream
Encapsulation (GSE) defined to support the second generation framing
structure defined by Digital Video Broadcasting (DVB) family of
specifications.

- Working Group Summary
There has been one WGLC on the document, raising a single issue that has
been solved completely.

- Protocol Quality
This document was reviewed by the working group secretary as well as the WG.
We feel that this document is ready, and implementors feel that the
specification is implementatble.