Extensions to Support Efficient Carrying of Multicast Traffic in Layer-2 Tunneling Protocol (L2TP)
draft-ietf-l2tpext-mcast-05

[Ballot discuss]
Section 3.2 (but also other sections) talks about a Vendor ID.
Not clear what that means.
In many cases when a spec talks about Vendor ID they mean a field
that should be able to contain the Vendor ID as assigned in
http://www.iana.org/assignments/enterprise-numbers

If that is the intent, then a 2 octet field seems too small.
There are many enterprise IDs already (21K+) and they are being added
at quite a reapid pace. 3 octets seems to be the minimal field for
such a vendorID.

OK, since these are all explicitly for VendorID zero,
I think that you are right that my concern is not justified,
specifically since this indeed comes from base spec in RFC2661.

IANA Comments:
Upon approval of this document the IANA will assign 5 new Message Type (Attribute Type 0) Values, 5 new Control Message Attribute Value Pairs,
and 4 Result Codes for the MSEN message.  These will be registered in

[Ballot discuss]
Section 3.2 (but also other sections) talks about a Vendor ID.
Not clear what that means.
In many cases when a spec talks about Vendor ID they mean a field
that should be able to contain the Vendor ID as assigned in
http://www.iana.org/assignments/enterprise-numbers

If that is the intent, then a 2 octet field seems too small.
There are many enterprise IDs already (21K+) and they are being added
at quite a reapid pace. 3 octets seems to be the minimal field for
such a vendorID.

[Ballot discuss]
Section 3.2 (but also other sections) talks about a Vendor ID.
Not clear what that means.
In many cases when a spec talks about Vendor ID they mean a field
that should be able to contain the Vendor ID as assigned in
http://www.iana.org/assignments/enterprise-numbers

If that is the intent, then a 2 octet field seems too small.
There are many enterprise IDs already (21K+) and they are being added
at quite a reapid pace. 3 octets seems to be the minimal field for
such a vendorID.

[Ballot discuss]
Section 3.2 talks about a Vendor ID. Not clear what that means.
In many cases when a spec talks about Vendor ID they mean a field
that should be able to contain the Vendor ID as assigned in
http://www.iana.org/assignments/enterprise-numbers

If that is the intent, then a 2 octet field seems too small.
There are many enterprise IDs already (21K+) and they are being added
at quite a reapid pace. 3 octets seems to be the minimal field for
such a vendorID.

[Ballot comment]
Reviewed by Brian Carpenter, Gen-ART

His review:

Summary: No objection

This draft suggests an optimization for multicast through
L2TP tunnels, such that the same flow will not be sent more
than once between the same two L2TP end-points. This is a
Good Thing if it can be achieved - it doesn't however
guarantee a logical multicast topology (any more than the
MBONE does). It is quite complex and adds some administrative
configuration tasks. Experimental seems appropriate, since it
isn't clear whether this will prove deployable at a large
scale.

The draft is quite well written, but I did notice one nit:

> 4.2.    Group state determination        Source Filtering Group
> Management Protocols require querier routers...

"querier" doesn't seem like an English word to me. Logically,
it should be, but I don't think it is. It certainly isn't
an adjective.

From: "BOURDON Gilles FTRD/DAC/ISS"
To: "Thomas Narten"
Cc: "Brian Haberman" , ,
  "Margaret Wasserman" ,
  "Isidor Kouvelas"
Date: Thu, 12 Feb 2004 09:52:39 +0100
Subject: RE : RE : TR : AD review of draft-ietf-l2tpext-mcast-03.txt
Thread-Topic: RE : TR : AD review of draft-ietf-l2tpext-mcast-03.txt
Thread-Index: AcPw2IldsbOq8nv1TuyLS+ACndN0PAAa+S2A

I planned to issue a new version of the draft including IGMPv3 in the next weeks. Moreover, I got similar requests from other people about that issue.
Unfortunately, I won't be able to edit the new version before Seoul cut-off date... I'll keep MAGMA chairmen in the loop.

Regards,

Gilles.