On Mon, Apr 7, 2008 at 1:15 PM, Hadriel Kaplan <[EMAIL PROTECTED]> wrote: > Howdy, > I have the following comments, mostly editorial nits, on the latest draft. > I think these do not overlap with John Elwell's. > > General comment: I think it's in great shape, and very thorough.
Thanks! > 1) I do not see any discussion of RFC 3680 SIP Registration Event Package. > I assume that each registered flow's contact is treated as a unique contact > in all regards to RFC 3680, right? And the reg-id and instance would be > saved in the "unknown-param" XML element of the contact element, making those > unique (vs. being unique contact URI's). I think maybe that should be > clarified somewhere, as rfc3680 is not uncommon. Paul K had an extension to reg-event for GRUU. I think his document would be a logical place to clarify since GRUU depends on outbound. > 2) If a Register is 3xx redirected, does the new retargeted Register use the > same reg-id, even though it's a different "flow"? (I assume so) I ask > because some people use 3xx for Registers to load-balance or perform > anycasting. It may be good to add this to end of section 4.2.1. Yes, the UA uses the same reg-id. It uses the the reg-id to indicate that this is (for example) my "2nd logical flow" to my registrar or the logical flow over my "cellular interface". Can you suggest something here or point out the specific part that is confusing.? > 3) Page 5: > Reg-id: "When a UA registers multiple times, each concurrent registration > gets a unique reg-id value." Replace with: "When a UA registers multiple > times, each for a different flow, each concurrent registration gets a unique > reg-id value." good > 4) Page 12, Section 3.5.2: > The proxy or registrar acts as a Session > Traversal Utilities for NAT (STUN) [I-D.ietf-behave-rfc3489bis] > server on the SIP signaling port. > Insert "limited" before "Session". (ie, it is not a full STUN server) good > 5) Page 12, Section 3.5.2: > Note: The STUN mechanism is very robust and allows the detection > of a changed IP address. > Add "and port" at the end. good > 6) Page 12, Section 4.1: > "It also provides an easy way to guarantee uniqueness within the AOR." I'm > a bit confused by that, because I don't believe we're saying one UA instance > only ever represents one AoR. (ie, multiple AoR's registered on the same UA > will have the same registered contact instance) Recommend removing or > rewording. I don't see the confusion. _Within_ the AOR, the instance-id provides further disambiguation. I can absolutely use the instance with more than one AOR. > 7) Page 14, Section 4.2.1: > For each outbound proxy URI in the set, the UAC SHOULD send a > REGISTER request using this URI as the default outbound proxy. (The > UA could limit the number of flows formed to conserve battery power, > for example). > The logic flow is awkward there. Change second sentence to start with > "Alternatively, the UAC could...". better > 8) Page 15, Section 4.2.1: > If the registering UA receives a 439 (First Hop Lacks Outbound > Support) response to a REGISTER request, it MAY re-attempt > registration without an outbound proxy (subject to local policy at > the client). > I think what you mean at the end is instead "without using the outbound > mechanism"? yes > 9) Page 16, Section 4.3: > ... For TLS protocols, there MUST also > be a match between the host production in the next hop and one of the > URIs contained in the subjectAltName in the peer certificate. > s/production in/resolved for/ I don't think your proposed rewording is correct. Perhaps s/next hop/next hop URI/ ? > 10) Page 18, Section 4.4.1: > A User Agent that forms flows, checks if the configured URI to which > the UA is connecting resolves to a stream-based transport (ex: TCP > and TLS over TCP). > That's confusing, because double-CRLF is used for connection-oriented > transports period, not only stream-based ones (ie, also used for SCTP). And > no statement is made about why it checks for stream-based, so I recommend > removing it or clarifying. How about: s/stream-based/connection-oriented/ ? thanks, -rohan > -hadriel > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
