Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)
RFC 4326

Note: This ballot was opened for revision 06 and is now closed.

(Margaret Cullen) Yes

(Brian Carpenter) (was Discuss) No Objection

Comment (2005-07-07)
No email
send info
Editorial comments on -06 version:

Gorry's latest statement is that the PP field is not formally part
of the TS header, and there are still a few placess where this needs to be made
consistent.

In 6.2 I found that

>    (The standard rules require the
>    header of this new TS Packet to carry a PUSI value of 1 and a
>    Payload Pointer value of 0x00.) 

occurs three times and needs slight fixing, e.g.

   (The standard rules require the
   header of this new TS Packet to carry a PUSI value of 1
   followed by a Payload Pointer value of 0x00.)

Gorry also proposed adding this somewhere:

  If the PUSI bit is set to a value of 1, there is one additional field
  following the TS packet header:
         *8b             Payload Pointer (PP)

(And there are formatting nits.)



-------------------------------------------------
from review of -05 version by Michael Patton:

The first use of "TS" in the Intro should probably be expanded.  It
was previously expanded in the Abstract, but you probably shouldn't
rely on readers having seen that recently...

Throughout the document there are references that get split across
line boundaries.  This should be avoided.

Section 1 has a reference to [draft-ipdvb-arch] which is not in the
references section.

At the end of Section 1 is a reference to [draft-ipdvb-ar] which is
not in the references section.

Section 2, in the def for AFC is a reference to [ISO_MPEG] which is
not in the references section.

Section 2, in the def of MPEG-2 there's mention of H.220 which could
usefully have a reference.

Section 2, in the def of PID the reference to "all 1s" is easy to
misread because the 1 looks like an l in some fonts.  I'd suggest
writing it as "all ones" to avoid potential confusion.  This
construction also appears in other places (Section 4.3 at least) which
should also be adjusted.

Section 2, has two slightly different definitions for PSI.

Section 4.6 has a ref to [ITU3563] which is not listed in the
	references section.

Is [ISO-8802-2] really 8802.2 rather than 802.2?

RFC3667 and RFC3668 appear in the references section, but are not
actually referenced (although 3668 is mentioned in boilerplate that
will go away in the RFC).  I don't think these belong here and they're
certainly not normative.

For IEEE 802.3 you use the IEEE ref and mention the ISO one, for 802.2
you only show ISO.  I think it might be better to make these
references consistent.


Typos:

Section 1, third line has a double open bracket ("[[").

Section 2, in the def of AFC: "ISO_MPEG" => "ISO-MPEG"

Section 2, in the def of SI Table, "that is been" => "that has been"

Section 2, in the def of TS Header there is a formatting error in the
		table.

In Section 2 the last paragraph (def of ULE Stream) is indented an
		extra space.

Section 2, in the def of ULE Stream: "ISO_MPEG2" => "ISO-MPEG2"

Section 4.4 "[IEEE 802.3;" => "[IEEE-802.3;"

In Section 5.1 "is of a Mandatory Extension Header"
	=> "is a Mandatory Extension Header"

In the diagram at the start of Section 6, the marks on the left and
right don't line up quite the same with the lower part.

(Bill Fenner) No Objection

(Ted Hardie) No Objection

(Sam Hartman) No Objection

(Scott Hollenbeck) No Objection

Comment (2005-05-24 for -)
No email
send info
I wish I knew what "Ultra Lightweight" meant.  The term is used in the title, but it doesn't appear to be explained.

(Russ Housley) No Objection

(David Kessens) (was Discuss) No Objection

(Allison Mankin) No Objection

Comment (2005-05-25 for -)
No email
send info
One needs to read the MPEG2 context in the intro to understand what "ULE" signifiies but that's the
nature of a spec.  I think it's quite a well-done spec, given its environment.

(Jon Peterson) No Objection

(Mark Townsley) No Objection

(Bert Wijnen) No Objection

Comment (2005-05-25 for -)
No email
send info
ANNEX B, page 41 states:

   Source IPv6:                  2001:660:3008:1789::5
   Destination IPv6:             2001:660:3008:1789::6

while RFC3849 has reserved 
  
    prefix  2001:DB8::/32 as a documentation-only prefix  in the IPv6
    address registry.  No end party is to be assigned this address.

(Alex Zinin) No Objection