Subject: Review of draft-ietf-mmusic-sap-v2-01.txt

From: Dave Thaler <[email-masked]>
Date: Tue, 1 Feb 2000 11:38:30 -0800 (PST)

Review of draft-ietf-mmusic-sap-v2-01.txt

The abstract and introduction specifically say that SAP is
implemented by _clients_.  My understanding is that in the
original framework, and in what the authors envision as a "good" solution,
SAP is actually implemented by _servers_, and you have a separate
mechanism to communicate between clients and servers (if they
are implemented as separate processes, unlike sdr).

If we support SAP, it will likely be on servers not clients (there's 
already a diagram in MSDN showing this), and I know there's been talk among 
the spec authors that sdr ought to change to do this as well.  Hence, 
I would like to see both the abstract and the introduction changed to 
reflect that current practice is not best practice, and that SAP is 
actually intended for server-server communication.  Section 10 is 
not sufficient to address my concern.

The rest of the draft after the intro looks fine in this regard
since it just uses "SAP announcer" etc except for the first
bullet item of appendix B which refers to "SAPv1 clients"
and should be "SAPv1 listeners" or some such term.

Regarding Authentication Header... why is this used instead of
IPsec AH (as the MZAP, etc specs use)?  I would have expected
to see a discussion of this somewhere (Security Considerations
at least), since doing per-protocol security is less secure in
the sense that you now have to worry about two implementations
(IPsec's and SAP's).

The rest of the spec looks fine to me.

-Dave

---

From: Mark Handley <[email-masked]>
Date: Tue, 01 Feb 2000 10:14:03 -0800

>the sense that you now have to worry about two implementations

I guess the main issue is deployment.  How long before IPsec becomes
sufficiently ubiquitous so a SAP sender can assume all SAP receivers
will be able to authenticate it?

If SAP ever moves to Proposed Standard, I'd propose we revisit this
issue then, but right now IPsec isn't really a viable deployed
solution (much though I wish it was).

Cheers,
	Mark

---

From: Colin Perkins <[email-masked]>
Date: Wed, 02 Feb 2000 00:21:49 +0000

>not sufficient to address my concern.

The current protoocol is intended to be agnostic in this regard, hence the
use of the announcer/listener terminology. Section 9 "Scalability and
caching" is to encourage the deployment of servers, and I'd expect another
draft to be produced eventually which would describe how those servers can
be accessed (which may be a new protocol, or simply a set of recommendations
on how to use existing protocols).

I'll fix the wording to make this clearer.

Colin