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:[email protected]]
> Sent: Thursday, June 28, 2012 9:05 PM
> To: Black, David
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]; [email protected]
> 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, <[email protected]> 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
> > [email protected] Mobile: +1 (978) 394-7754
> > ----------------------------------------------------
> >
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
