[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MMUSIC] Comments on draft-rosenberg-mmusic-ice-nonsip
I think the real meta-question on this draft, is whether:
a. it is the same functionality as ICE, but not tied to SIP
b. it is (a) plus a subsetting, removing features that we think only
SIP needs
The list of things in the (b) bucket that I removed were:
1. multiple streams
2. multiple components per stream
3. updating ICE parameters mid-negotiation
4. restarting ICE
5. role conflict detection
6. ICE mismatches
7. default candidates
8. ice-lite
9. forking support
10. frozen algorithm
11. remote candidates mechanism
So first we need to decide path a or b, and then we can discuss which of
the above get included or not.
few more comments below:
Philip Matthews wrote:
> 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.
OK. I got a few folks that said they hated this MIME thing. THe
intention was that it was optional - there if you want it. I think it
would be a fine idea to have a section that also lists the params you'd
need to include if you didn't use the MIME object.
>
>
> 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".
OK.
>
> * 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.
Hmm, well I thought it was confusing to use the same terms when this is
not based on O/A anymore.
-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D. 499 Thornall St.
Cisco Fellow Edison, NJ 08837
Cisco, Voice Technology Group
jdrosen at cisco.com
http://www.jdrosen.net PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic