These resolutions have been carried forward to the -13 version of the draft. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Friday, July 13, 2012 6:25 PM > To: Black, David; alan.b.johnston@xxxxxxxxx; mohsen.soroush@xxxxxxxxxxxx; > vvenkatar@xxxxxxxxx; gen-art@xxxxxxxx > Cc: Shida Schubert; bliss@xxxxxxxx; IETF Discussion; Robert Sparks > Subject: Gen-ART review of draft-ietf-bliss-shared-appearances-12 > > The -12 version of this draft resolves all of the comments in the > Gen-ART review of the -11 version. > > Thanks, > --David > > > -----Original Message----- > > From: Black, David > > Sent: Thursday, June 28, 2012 4:51 PM > > To: alan.b.johnston@xxxxxxxxx; mohsen.soroush@xxxxxxxxxxxx; > > vvenkatar@xxxxxxxxx; gen-art@xxxxxxxx > > Cc: Black, David; Shida Schubert; bliss@xxxxxxxx; IETF Discussion; Robert > > Sparks > > Subject: Gen-ART review of draft-ietf-bliss-shared-appearances-11 > > > > 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. > > > > 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? > > > > 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". > > > > If the Appearance Agent policy does not allow this, a 400 response > > is returned. > > > > Same question. In addition, is 403 Forbidden allowed 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. > > > > 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. > > > > 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?). > > > > 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. > > > > Please ensure that the section 6 XML and Section 7 ABNF are > > syntax-checked with actual tools. > > > > 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. > > > > 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 > > ----------------------------------------------------