David, I will make those changes. Thanks for the feedback. - Alan - On Fri, Jun 29, 2012 at 8:43 AM, <david.black@xxxxxxx> wrote: > Alan, > > Thank you for the quick response. I have a few comments on the proposed > resolutions. Absence of a comment implies that I agree with the proposed > resolution. > > REQ-16 - I understand what's going on here (automatic ringdown), but the > language is just slightly off because there is actually a dialing request. > Here's all of REQ-16: > > REQ-16 The mechanism should support a way for a UA to seize a > particular appearance number and also send the request at the same > time. This is needed when an automatic ringdown feature (a telephone > configured to immediately dial a phone number when it goes off hook) > is combined with shared appearances - in this case, seizing the line > is the same thing as dialing. > > The language problem is that the line seizing includes a dialing request, > so "is the same thing as" isn't quite correct when applied solely to > "seizing the line". As you suggest, the simplest fix would be to just > remove "- in this case ... dialing", or it could be changed to: > > - in this case, seizing the line is part of dialing. > > 5.3 - Doing nothing is fine. I'm not a SIP expert, so I assume that > the standard PUBLISH behavior (soft-state times out if not refreshed) > is well-known to anyone who is, and hence no change is needed. > > 5.4 - please add "(Bad Request)" after each of the two instances of "400". > > 9.1/2/3 - please change to using "SHOULD" in each of these sections > and explain that the "SHOULD" is motivated by user experience concerns. > > Thanks, > --David > >> -----Original Message----- >> From: Alan Johnston [mailto:alan.b.johnston@xxxxxxxxx] >> Sent: Thursday, June 28, 2012 9:05 PM >> To: Black, David >> Cc: mohsen.soroush@xxxxxxxxxxxx; vvenkatar@xxxxxxxxx; gen-art@xxxxxxxx; >> shida@xxxxxxxxxx; bliss@xxxxxxxx; ietf@xxxxxxxx; rjsparks@xxxxxxxxxxx >> Subject: Re: Gen-ART review of draft-ietf-bliss-shared-appearances-11 >> >> David, >> >> Thank you for your review of the document. See below for how I >> propose to resolve the issues you have raised. Let me know if you >> have any other issues or concerns. >> >> - Alan - >> >> On Thu, Jun 28, 2012 at 3:51 PM, <david.black@xxxxxxx> 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-bliss-shared-appearances-11 >> > Reviewer: David L. Black >> > Review Date: June 28, 2012 >> > IETF LC End Date: June 28, 2012 >> > IESG Telechat date: (if known) >> > >> > Summary: >> > >> > This draft is on the right track but has open issues, described in the >> review. >> > >> > This draft describes support for shared appearances in support of multi-line >> > and shared-line telephone often found in businesses. All of the open issues >> > are minor. The draft is well-written and reasonably clear for the most >> part, >> > although significant SIP expertise is required to completely understand it. >> > >> > Major issues: None. >> > >> > Minor issues: >> > >> > 4.1 - REQ-16: >> > >> > in this case, seizing the line is the same thing as dialing. >> > >> > That seems wrong - I would have thought it was a "prerequisite" as >> > opposed to "the same thing" because seizing the line is immediately >> > followed by a dialing request. >> >> >> This requirement is about sending one request that causes both actions >> to occur. In a PSTN ringdown circuit (a very specialized circuit, >> used for "hotlines"), the two operations are the same thing. Besides >> this statement, is REQ-16 itself not clear? Perhaps I should just >> remove this statement if it adds confusion rather than clarity to the >> requirement. >> >> > >> > >> > 5.3. >> > >> > A user may select an appearance number but then abandon placing a >> > call (go back on hook). In this case, the UA MUST free up the >> > appearance number by removing the event state with a PUBLISH as >> > described in [RFC3903]. >> > >> > What happens when that can't be done due to UA or network failure? >> >> >> A little further down in this section says: >> >> " This publication state is refreshed as described in [RFC3903] during >> the early dialog state or the Appearance Agent may reassign the >> appearance number." >> >> So if the removal publish is lost, it will eventually timeout since it >> is not refreshed. This is standard PUBLISH behavior described in RFC >> 3903. >> >> > >> > >> > 5.4. >> > >> > A 400 response is returned if the chosen appearance number is invalid, >> > >> > Is that always a 400 (Bad Request) or is any 4xx response allowed? If >> > it's always 400, add the words "Bad Request" after "400". >> >> We chose 400 in particular, although any 4xx response would have the >> same result. "Bad Request" is the reason phrase, and the practice of >> putting it in () is a convention commonly used in SIP documents. The >> actual reason phrase can be different, customized ("Invalid >> Appearance") if desired, or in a different language. >> >> So in this case we are specifying the 400 response. >> >> > >> > If the Appearance Agent policy does not allow this, a 400 response >> > is returned. >> > >> > Same question. In addition, is 403 Forbidden allowed here? >> >> 403 is usually used in SIP to indicate that the request has failed due >> to an authorization policy, and the request can be retried with >> different credentials. That doesn't quite fit here. >> >> > >> > If an INVITE is sent by a member of the group to the shared AOR (i.e. >> > they call their own AOR), the Appearance Agent MUST assign two >> > appearance numbers. The first appearance number will be the one >> > selected or assigned to the outgoing INVITE. The second appearance >> > number will be another one assigned by the Appearance Agent for the >> > INVITE as it is forked back to the members of the group. >> > >> > How does that interact with the single appearance UAs in 8.1.1 that won't >> > understand the second appearance number? A warning that such a UA can't >> > pick up its call to its own AOR would suffice, either here or in 8.1.1. >> >> I will put text in 8.1.1 that makes this point clear. >> >> > >> > 9.1 >> > >> > A UA that has no knowledge of appearances must will only have >> > appearance numbers for outgoing calls if assigned by the Appearance >> > Agent. If the non-shared appearance UA does not support Join or >> > Replaces, all dialogs could be marked "exclusive" to indicate that >> > these options are not available. >> > >> > Should that "could be marked" be changed to "SHOULD be marked" ? >> > Also, analogous questions for "could" in 9.2 and "can" in 9.3. >> > >> > All three of these affect interoperability. >> >> I can change this to SHOULD. Actually, it doesn't affect >> interoperability, as "exclusive" is just a hint, for user experience >> and interface purposes and to reduce failed requests. If a Join or >> Replace is inadvertently sent, the operation will fail, which is the >> same result as not allowing it, although a worse user experience. >> >> > >> > 12. Security Considerations >> > >> > In general, this section is weak on rationale - the second, third and >> > fourth paragraphs should all explain more about the purpose of and/or >> > rationale for their security requirements (e.g., what does the security >> > mechanism protect against and when/why might that protection be desired >> > and/or required?). >> >> Right, the mechanisms are to provide privacy and to prevent >> hijacking/spoofing. I can add text to make this clear. >> >> > >> > NOTIFY or PUBLISH message bodies that provide the dialog state >> > information and the dialog identifiers MAY be encrypted end-to-end >> > using the standard mechanisms. >> > >> > What are "the standard mechanisms"? List them, and provide references, >> > please. >> >> That would be S/MIME as described in RFC 3261. I can add this. >> >> > >> > Please ensure that the section 6 XML and Section 7 ABNF are >> > syntax-checked with actual tools. >> >> I will double check them. >> >> > >> > Nits/editorial comments: >> > >> > p.10: >> > >> > The next section discusses the operations used to implement parts of >> > the shared appearance feature. >> > >> > "The following list describes the operations ..." would be better. >> > >> > 5.3.1. >> > >> > A UA wanting to place a call but not have an appearance number >> > assigned publishes before sending the INVITE without an 'appearance' >> > element but with the 'shared' event package parameter present. >> > >> > I think I understand what was intended here, but this would be clearer >> > if "publishes" was replaced with language about sending a PUBLISH. >> > It's also not completely clear whether "without" applies to the >> > INVITE or the PUBLISH, so this sentence probably needs to be reworded. >> >> OK, it is the PUBLISH that doesn't have the parameter - I'll make this clear. >> >> > >> > 5.4. - Expand B2BUA acronym on first use. >> > >> > idnits 2.12.13 ran clean. >> > >> > Thanks, >> > --David >> > ---------------------------------------------------- >> > David L. Black, Distinguished Engineer >> > EMC Corporation, 176 South St., Hopkinton, MA 01748 >> > +1 (508) 293-7953 FAX: +1 (508) 293-7786 >> > david.black@xxxxxxx Mobile: +1 (978) 394-7754 >> > ---------------------------------------------------- >> > >