Selectively Reliable Multicast Protocol (SRMP)
draft-pullen-srmp-06

[Ballot comment]
Wrong boilerplate - how did this even get posted in June 2005?

  SRMP identifies sender and receiver using their 32-bit Sender_ID,
  which may be an IPv4 address. For use with IPv6, a user group will
  need to establish a unique identifier per host. There is no
  requirement for this identifier to be unique in the Internet; it
  need only be unique in the communicating group.

If this was standards track, I would be concerned about this - not about
limiting the ID to 32 bits, but about the mechanism for ensuring
uniqueness within the group. In a NATed network, even IPv4 addresses
aren't unique.

Reviewed by Lorenzo Vicisano who supports Experimental publication.  Need
to add a note on not wanting to cause a negative impact on the ISO similar
spec.  Should this be Experimental or Informational in that regard?  Probably
should ask them?

Date:    Mon, 14 Mar 2005 10:14:12 PST
To:      mankin@psg.com
From:    Lorenzo Vicisano
Subject: Pullen's SRMP



Allison,

Mark Pullen has been talking to me about this "mixed transport" draft
(draft-pullen-srmp-05.txt).

I'm very reluctanct about accepting this as a WG item for 2 reasons:
the draft covers an area that is not directly in the RMT scope.
Besides, I don't think it is a good idea to dilute the scarce energy
of the WG.

Said that, this spec has probably a reason to exist, so, in the lack of
better alternatives, I would be supportive to make this an individual
submission for experimental.

Please let me know what you think.

Please also see the attached email from Mark Pullen, where he talks
about the dependendies between this draft, his founding for itef work
and his involvment with tfmcc.

        cheers,
        Lorenzo

- it needs to reference RFC 2357 about scaling, cc, and security
- the use of TFMCC for variable length is a handwave, at least
  say that the future work on variable length will be adopted -
  maybe the protocol needs to be more modular to accomodate
  changing to the new algorithm easily
- it must  expand the security considerations -
  use those in the ALC Protocol Instantiation (RFC 3450)
  as a guideline for the kinds of questions that should be
  addressed.  Even for an Experimental, when it's a multicast
  transport protocol, there is a pretty high bar on at least
  articulating the risks of the protocol being usable for
  amplification attacks in particular, but also risks to the
  user, difficulties of obtaining security services on the
  data, e.g.