[MMUSIC] Comments on draft-rosenberg-mmusic-ice-nonsip

[Philip Matthews <philip_matthews at magma.ca>]

Below are some comments on this draft. I have grouped the comments by  
subject matter.

Comments on the subset of ICE chosen:
* I think this draft should allow multiple streams between the two  
clients. I feel this is useful in non-SIP contexts. For example, my  
draft draft-matthews-p2psip-id-loc requires multiple streams for non- 
SIP purposes. I suggest this draft simply point out the  
simplifications that occur if there is only one stream.


Comments on the MIME object:
* I think this draft should not require the MIME object of section  
15, but simply present it as one possible encoding. The draft should  
instead list the parameters that ICE needs as input, and allow  
protocols to use other encodings instead. Protocols may also derive  
some of these ICE-related parameters from other fields in their  
protocol messages, rather than pass them explicitly.
For example, right now the HIP work is proposing to use an encoding  
that is more consistent with HIP. HIP is a binary protocol, so a text- 
based encoding seems a bit out-of-place. Moreover, the HIP work is  
proposing to not generate an ICE-specific username fragment and  
password, but use the Host Identity Tag (HIT) as the username  
fragment, and the keying material derived from the Diffie-Helmman  
exchange as the password. Thus these fields of the MIME object are  
not needed for HIP.


Comments on Terminology:
* I dislike the term "session protocol". In SIP/SDP, it is the direct  
connection which is the "session", not the signaling protocol, so the  
"session protocol" should be the protocol that runs over the direct  
connection. I suggest that you replace the sentence "NICE works only  
with protocols that fit the pattern of a session protocol" with "NICE  
only works with signaling protocols that have a rendezvous mechanism".

* In section 2, the document talks about establishing sessions  
between "hosts". I think it should instead talk about sessions  
between clients or protocol instances or similar.

* The document introduces the terms "Initiate Message/Accept Message"  
and "Initiator/Responder" in place of ICE's "Offer/Answer" and  
"Offerer/Answerer". Though the new terms might be better than the  
existing terms, I think it will just be confusing to have to  
different sets of terms for the same concept. Anyone who implements  
NICE and any protocol designers who use NICE will have to at least  
skim draft-ietf-mmusic-ice and become familiar with the Offer/Answer  
terminology there, so I don't see the point of introducing new  
terminology.



Other Comments:
* The comment about ICE depending on the confidentiality and  
integrity of the offer/answer exchange is an important one and should  
not be buried in the Security Considerations section. Instead, I  
suggest you add this to the section on "Can my protocol use NICE?",  
which should become a normative section (rather than an informative  
section)


- Philip

_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic