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

Dave Thaler <dthaler@dthaler.microsoft.com> Tue, 01 February 2000 18:01 UTC

Return-Path: <owner-confctrl>
Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id KAA14154 for confctrl-outgoing; Tue, 1 Feb 2000 10:01:20 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA14149 for <confctrl@zephyr.isi.edu>; Tue, 1 Feb 2000 10:01:19 -0800 (PST)
Received: from dthaler.microsoft.com ([131.107.152.20]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA08621 for <confctrl@ISI.EDU>; Tue, 1 Feb 2000 10:01:40 -0800 (PST)
Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id LAA27292; Tue, 1 Feb 2000 11:38:30 -0800 (PST) (envelope-from dthaler)
From: Dave Thaler <dthaler@dthaler.microsoft.com>
Message-Id: <200002011938.LAA27292@dthaler.microsoft.com>
Subject: Review of draft-ietf-mmusic-sap-v2-01.txt
To: confctrl@ISI.EDU
Date: Tue, 01 Feb 2000 11:38:30 -0800
X-Mailer: ELM [version 2.4ME+ PL43 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

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