-----Original Message-----
From: Alan Johnston [mailto:alan(_dot_)b(_dot_)johnston(_at_)gmail(_dot_)com]
Sent: Thursday, June 28, 2012 9:05 PM
To: Black, David
Cc: mohsen(_dot_)soroush(_at_)sylantro(_dot_)com;
vvenkatar(_at_)gmail(_dot_)com; gen-art(_at_)ietf(_dot_)org;
shida(_at_)ntt-at(_dot_)com; bliss(_at_)ietf(_dot_)org;
ietf(_at_)ietf(_dot_)org; rjsparks(_at_)nostrum(_dot_)com
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(_dot_)black(_at_)emc(_dot_)com>
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(_dot_)black(_at_)emc(_dot_)com Mobile: +1 (978) 394-7754
----------------------------------------------------