Re: Request for review of draft-wu-rgmp-01.txt

(CC to [email protected] as well because some comments have been sent
to that list instead)

>  The IESG received a request to publish draft-wu-rgmp-01.txt
>  as an Informational RFC. While considering this request,
>  it was identified that the subject of the draft may overlap
>  with some work done by the IDMR WG.
> 
>  The ADs would like to ask the WG to review this I-D and
>  provide comments on it by April 26th. Following are the types
>  of feedback we're looking for:
>  
>    1. Technical quality and usefulness of this work.
> 
>    2. Whether the WG considers this I-D an end-run
>       around the WG's efforts.
> 
>    3. Whether this document should be published as an
>       Informational RFC.
> 
>  Please note that the draft describes a proprietary protocol,
>  which has been implemented and deployed, and the authors are
>  interested in keeping the protocol operation as described.
> 
>  Also, be advised that we have been notified of intellectual
>  property rights claimed in regard to some or all of
>  the specification contained in this document. The authors
>  have been asked to follow the procedure and file an official
>  IPR disclosure with the IETF executive director.


Two technical comments from me:


* Why IPv4-specific?
  (Though I may be missing some IPv6 solution that does that
  already :)
  E.g., make the Group Address 32 bits for IPv4, and 128 bits for
  IPv6. Then add a sentence that the address family of Group
  Address (and therefore its size resp.) must match the address
  family of the IP message that carries it.
  In addition, use "MLD/IGMP" instead of "IGMP",
  and specify the corresponding IPv6 mcast group
  addresses mentioned in the draft.
  
* What about SSM?
  There was no Source Address in the message format, so
  is RGMP "approximating" (S,G) with (*,G) by considering the Group
  Address only?

  E.g., you can add an optional "Source Address" right after "Group
  Address". 
  Because the message length is fixed, if there are 32 bits/128 of data
  (for IPv4/IPv6 resp.) after "Group Address", that extra data would
  be "Source Address".
  Note that this solution should be compatable with implementation
  that use the current format.
  Alternatively, you can specify different message types
  that carry a Source Address as well.
  
Thanks,
Pavlin