Re: [BLISS] Review of draft-ietf-bliss-ach-analysis-06.txt

["Elwell, John" <[e-mail]>]

Scott, 

(Shortened in places)

> -----Original Message-----
> From: Scott Lawrence [mailto:[e-mail]] 
> Sent: 28 April 2010 16:53
> To: Elwell, John
> Cc: Scott Lawrence; [e-mail]
> Subject: Re: [BLISS] Review of draft-ietf-bliss-ach-analysis-06.txt
> 
> On Fri, 2010-03-19 at 19:40 +0100, Elwell, John wrote:
> 
> > Thanks for your review. Responses below. 
> 
> 
> > >   While many readers may believe that they understand 
> what HERFP is, I
> > >   don't think it's appropriate to either assume that they 
> all believe
> > >   the same thing, or leave the uninitiated in the dark.  I suggest
> > >   either finding an existing description appropriate to reference,
> > >   adding an appendix to include one, or replacing this 
> shortcut with
> > >   some short description of what happens.
> 
> > [JRE] Added a short description: "HERFP is where different forked-to
> > UASs return different error responses, yet in accordance 
> with RFC 3261
> > rules for forking proxies, only one of these reaches the 
> UAC. Thus an
> > error response of possible significance may not reach the UAC."
> 
> That's what I had in mind - a wording suggestion:
> 
>         'HERFP' is shorthand for a common problem with error responses
>         to requests forked at a proxy; if multiple UAs return error
>         responses to such a request, RFC 3261 requires that the proxy
>         forward only one error response to the UAC. Thus an error
>         response of possible significance may not reach the UAC.
[JRE] OK, I will adopt these words.

> 
> > > Section 7.1:
> > > 
> > >   I don't know that the two normative (MUST) statements 
> here actually
> > >   make any sense in practice, and in any event they are not very
> > >   specific.
> 
> > [JRE] Perhaps SHOULD? But I don't like that. We are trying 
> to improve
> > interoperability, and the conclusion was that by turning off ACH
> > features at the UA, leaving it to the proxy, a certain class of
> > interoperability problem can be avoided.
> 
> > >   What does a UA having 'all ACH features turned off' really mean?
> > >   Never return a 3xx response?  Never return a 486 busy response?
> > >   Disable the 'Do Not Disturb' button?  Don't give the 
> user the option
> > >   to reject a call?
> 
> > [JRE] It means responding to indicate the state, and 
> leaving the proxy
> > to determine any subsequent action.
> 
> > >   Similarly, what does it mean that a proxy must 'operate 
> when ACH is
> > >   provided by the registered UA'?  That the proxy cannot 
> implement any
> > >   redirection or retargeting?  If so, then the assertion that this
> > >   'typically would be the default configuration' is 
> certainly not true
> > >   of any system I've encountered.
> 
> > [JRE] Normally an out-of-the-box proxy has all ACH features turned
> > off. It will need some configuration to cause forwarding 
> from A to B,
> > for example, this can never be default.
> 
> My real point is that I'm not sure that there is any value in making
> statements about what is 'typically' true.  Any system that includes a
> voicemail service that I've ever seen includes sending calls to
> voicemail by default when not answered.
[JRE] I have deleted the bits about typically being the default configuration.

> 
> I certainly agree that it should be possible to tell either a 
> proxy or a
> UA not to do any redirection or retargeting... if you like MUST for
> that, that's fine.
> 
> > > Section 7.2 says:
> > > 
> > >    o  Response code 487 for silent rejection/local.  This 
> is the same
> > >       response code that would be used if a proxy were to 
> > > issue a CANCEL
> > >       request.
> > > 
> > >   That's a new (to me, at least) usage that does not seem 
> to me to be
> > >   within the meaning given to it by 3261:
> > > 
> > >     The request was terminated by a BYE or CANCEL request.  
> > > This response
> > >     is never returned for a CANCEL request itself.
> 
> > [JRE] Exactly, if I send a CANCEL, the UA will respond to 
> the INVITE with 487.
> 
> My reading of that suggestion was that if my phone rings, and I press
> the 'reject silently' button on my phone, then it should send 487.  I
> don't think that's correct behavior because there was no 
> CANCEL from the
> UAC.  If that's not what you meant, then that section is confusing.
[JRE] I have changed the wording to say: "This is the same response code that would be used to reject an INVITE request if a proxy were to issue a CANCEL request."

[JRE] I would like to issue an -07, but prefer to wait until there has been some discussion on the thread I initiated on 15th April.

John