A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer
draft-ietf-mmusic-file-transfer-mech-11

I'm concerned by the creation of yet-another-file-transfer mechanism.  As
if we didn't have enough with FTP, SFTP, SCP, TFTP, HTTP, RCP,
RSYNC, etc.  Did the authors evaluate reusing existing file transfer
technology and enhancing it to support the missing features, as
necessary?  I can perhaps see the justification for some of the SDP
negotiation, but this is a very monolithic architecture rather than
a more traditional Internet component-based architecture.  This seems
to be re-inventing a traditional IETF application.

I'm also concerned by the complexity of this architecture, particularly
given that it potentially mixes generic file transfer in the same stream
with IM traffic and IM attachments creating a potentially nasty content
dispatching problem as well as a multiplexing problem (something that
has deployed poorly in the applications layer with SSH being perhaps the
sole exception of a widely deployed/used channel multiplexing
technology at that layer).

Although I'm not a huge fan of our media feature standards due to their
complexity, they are the standards we have for cases where one endpoint
is requesting content that meets certain characteristics from another
endpoint.  Why were these existing standards not used?  Was reuse at
least evaluated?  I note the lemonade WG was specifically constrained
to reuse media features by its charter so there are people who feel
strongly about this in the IETF community.  The lemonade WG ended up
reusing the feature tag registry, although not the rest of the framework
based on complexity evaluation.

I'm putting these three issues in a comment as I don't see them as
actionable and thus will not hold a blocking discuss over these issues
(although I may choose to abstain on this document after IESG
discussions).

I too would have wanted to see negotiation of existing file transfer mechanisms as opposed to a new one. Is this mechanism deployed, and have the other IM protocols done for the same functionality? There may of course be reasons why an integrated file transfer mechanism is needed.

C1. Section 6: ABNF errors

attribute            = file-selector-attr / file-disp-attr /
                          file-tr-id-attr / file-date-attr /
                          file-icon-attr / file-range-attr
                          ;attribute is defined in RFC 4566

This would if combined with the RFC 4566 ABNF override the attribute definition which I don't think the intention is. One way to express this correct would be to use the /= between the rulename and the rule extension. 

   filetype-selector    = "type:" type "/" subtype *(";"parameter)

There is a missing white space between ";" and parameter

C2. Section 6: 

I think there might be good to be clearer in the text around the below sentence that all 160 bits of the SHA-1 output is included:

   Implementations according to this
   specification MUST add a US Secure Hash Algorithm 1 (SHA1) [RFC3174]
   value if the 'hash' selector is present.

I've seen multiple implementations of this already - it is alive in the wild. 

I'm agree that better tools for describing what would be accessed would make a more robust system and hope that future work explores that avenue.

Section 5, para 3 sentence 2
s/selects those file/selects those files/

Section 10, last sentence

s/to dismiss the risk of damage/to mitigate the risk of damage/
(if you don't like mitigate, limit or reduce would work, too!)