Begin forwarded message: > From: Alan Johnston <[email protected]> > Date: October 27, 2011 10:53:27 AM CDT > To: Ben Campbell <[email protected]> > Cc: [email protected], "[email protected] Review > Team" <[email protected]>, "[email protected]" <[email protected]> > Subject: Re: Gen-ART Last Call review of draft-ietf-cuss-sip-uui-reqs-06 > > Ben, > > Thanks for your review of the draft. See my comments below. I have also > revised the draft as draft-ietf-cuss-sip-uui-reqs-07 which I believe > addresses all the issues. > > - Alan - > > On Oct 12, 2011, at 4:27 PM, Ben Campbell wrote: > >> I am the assigned Gen-ART reviewer for this draft. For background on >> Gen-ART, please see the FAQ at >> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >> >> Please resolve these comments along with any other Last Call comments you >> may receive. >> >> Document: draft-ietf-cuss-sip-uui-reqs-06 >> Reviewer: Ben Campbell >> Review Date: 2011-10-12 >> IETF LC End Date: 2011-10-13 >> >> Summary: This draft is almost ready for publication as an informational RFC. >> I have a few minor questions and comments that may be worth addressing first. >> >> Major issues: >> >> None >> >> Minor issues: >> >> -- section 1, 2nd paragraph, last sentence: "In particular, this mechanism >> creates no requirements on intermediaries such as proxies." >> >> What about SBCs, B2BUAs, etc? > > There are no requirements on them either - we'll add text saying that. > >> >> -- REQ-4: "… any other form of redirection of the request." >> >> "Any other form" seems a pretty strong statement. What about a b2bua doing >> weird stuff? > > Sure, no protocol mechanism can prevent a B2BUA from doing something. We > will clarify to just say redirection, since that operation is well defined in > RFC 3261. > >> >> -- REQ-8: "If the UAS does not understand the UUI mechanism, the request >> will fail." >> >> Based on the routing requirement, shouldn't that say that if the request >> cannot be routed to a UAS that understands the UUI mechanism, the request >> will fail? > > Yes, this is clearer. > >> >> -- REQ-12: >> >> What degree of certainty is required here? (i.e. strong identity?) If >> implied by the SIP dialog, does that impact expectations on what sort of >> authn must happen at the SIP layer? > > This is not meant to imply strong identity. And since UUI data can appear in > a response, there aren't really any strong methods available with SIP. The > UUI mechanism does not introduce stronger authorization requirements for SIP, > but instead the mechanism needs to be able to utilize existing SIP approaches. > >> >> -- REQ 13: >> >> I'm not sure I understand how this interacts with the ability for >> intermediaries to remove UUI. Should this be detectable by the endpoints? Or >> is that ability limited to the hop-by-hop case, or require no integrity >> protection? > > Yes, there are tradeoffs between this requirement and requirement REQ-9. > Hop-by-hop protection is one way to resolve this interaction. > >> >> Nits/editorial comments: >> >> -- section 4, 2nd paragraph: "The UUI mechanisim should support both of >> these approaches" >> >> Should that be a numbered requirement? You've got requirements to support >> e2e and hop-by-hop, but no requirement that mentions SIP layer vs >> application layer. > > Actually, this sentence is misplaced. There isn't really a requirement to > support both of these. I'll remove it to avoid confusion. > > >
_______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
