Re: [BLISS] AD review: draft-ietf-bliss-shared-appearances-06

[Alan Johnston <[e-mail]>]

I am finally working on a revision to the document.  See below for
comments on the minor issues.  There hasn't been any comments on the
major issues (changing 409 with 400 and updating RFC 3261 and 4235).

Comments most welcome.  I should have the changes described here done
in the next few days.

- Alan -

On Fri, Dec 17, 2010 at 10:17 AM, Alan Johnston
<[e-mail]> wrote:
> Robert,
>
> Thanks for your review of this document.  I plan to address all of
> your comments in a revision early in January.  For now, I will reply
> to your three major issues below and see if we can get working group
> consensus on the resolutions.
>
> - Alan -
>
> On Mon, Dec 6, 2010 at 1:58 PM, Robert Sparks <[e-mail]> wrote:
>> Summary: There are a few major issues that need to be addressed before progressing this document.
>>
>> Major Issues:
>>
>> 1) 409 is not a defined response code. Probably easiest to choose another.
>>
>
> I knew 409 was deprecated as a response to REGISTER, but I hadn't
> realized we had deprecated the entire response code!
>
> I suggest we just use a 400 response.  We had discussed including a
> Retry-After header field with a very short value, or even zero, but
> now I'm thinking about just omitting the Retry-After.
>
>
>> 2) Is this an update to 3261 (through adding a parameter to Alert-Info)?
>
>
> I am OK with this.
>
>>
>> 3) Is this an update to 4235 (through adding the shared parameter)?
>>
>
> I am OK with this.  We also make recommendations about dialog package
> notifications that is stronger than RFC 4235, so this makes sense.
>
>
>> ----
>>
>> Section 4.2 calls out "An analysis of other mechanisms has been performed".
>> Has that analysis been captured?

It is in earlier versions of the I-D but was deleted.  I will remove this text.

>>
>> The list of steps in 4.2 is intended to be illustrative (I think). Can
>> text be added to reinforce that this is not defining behavior. It might
>> also help to point to where the behavior is actually defined.

Right, we'll emphasize this is non-normative, and point to 5.3 and 5.4
where this is defined normatively.

>>
>> In 4.2, step 7, it's not clear what "this" is in "publishes this"

The UA publishes the 100 Trying state dialog information without an
appearance number.  I'll add this in.

>>
>> Suggest deleting "In some cases," from the start of 4.2 step 9.

Right

>>
>> The second paragraph of 5.2.2 should be clearer - it's not obvious
>> that what you're trying to recommend is that a UA not share dialog
>> information so that it won't be possible for someone else to take the
>> call from a remote peer.

Right, we will clarify this.

>>
>> Section 5.3 : why are the SHOULDs in paragraphs 2 and 3 (not counting
>> the note between them), SHOULD and not MUST?

I can't think of any reasons or cases where a UA that conforms to this
specification wouldn't, so I'll change them to MUSTs.

>>
>> Section 5.3, paragraph 3: Should this say "fails or loops back to itself"?
>> Or is looping back the only failure you were intending to describe? What
>> period should UAs retry the subscription with?

No, it should just say "fails".  A very long retry interval would seem
to be in order - perhaps 4 hours?

>>
>> Section 5.3, paragraph 4 "All User Agents supporting INVITE MUST support...".
>> This hasn't captured the real requirement - it's not All User agents that
>> support INVITE in the world - did you intend to scope this to "implement
>> call pickup, joining, and bridging as you did in the first sentence?

No, the MUST is for any UA that supports this specification and
supports receiving INVITEs.  I will make this clearer.

>>
>> Section 5.3, top of page 15: "This publication state SHOULD be refreshed"
>> Why is this a SHOULD? When would the endpoint choose to let the published
>> state expire? It might help to call out that you are talking about normal
>> 3903/5264 soft-state refreshes here.

Right - we are not trying to make any changes to normal refresh
operation, so I will remove the normative language.


>>
>> Section 5.3, middle of page 15: what does "implicitly rendered" mean?

Explicitly rendered means show the actual appearance integer in the
UI.  Implicitly means some other clever UI trick that preserves the
ordering aspects and makes sense to users within the group.

>>
>> End of section 5.3 - informative note. typo: received->receive. It would
>> probably help to call out that this NOTIFY will be on the dialog event
>> package.

OK

>>
>> Section 5.4 - The SHOULD at the end of the 2nd paragraph is either
>> modifying or restating a requirement from 4235. The Appearance Agent
>> is being a State Agent at this point and the event package defines
>> when change is sufficient to trigger a NOTIFY. It looks like this is
>> in fact modifying the rules in 4235, adding extra conditions on
>> when NOTIFYs would be sent. It would be much clearer to state this in
>> terms of the affect on the package.

This is all RFC 4235 says "It is RECOMMENDED that NOTIFY requests only
contain information on the dialogs whose state or participation
information has changed." which is very vague.  The four items in this
draft are:
   1.  A call is received, placed, answered, or terminated.
   2.  A call is placed on or off hold.
   3.  A call is joined or replaced.
   4.  An appearance number is reserved or released.
I think 1 is covered by 4235.  2 could be covered if hold/unhold is
considered participation, but I think not.  I don't think 3 and 4 are
covered.  I can write some text that says explains how this
specification extends 4235 by adding 2, 3, and 4.

>>
>> Section 5.4 talks about proxies inserting an Alert-Info field. Section
>> 11 talks about proxies inserting and removing them. Both of these sections
>> use non-normative terms. Where is the normative behavior for proxies participating
>> in this feature defined? Also, for section 11. "If an Alert-Info is already present,
>>  the proxy either removes the Alert-Info if it is not trusted, or adds
>>  the 'appearance' parameter to the Alert-Info header field."
>> It's not clear that RFC3261 allows a proxy to modify (in particular delete)
>> existing Alert-Info header fields.

You are correct that RFC 3261 does not explicitly allow this, although
every real system does so.  I would prefer to update RFC 3261 to
explicitly allow proxies to apply trust domain rules in modifying and
deleting Alert-Info header fields and parameters.  However, if this
causes trouble, we can remove it.  I'm working on some text for this.

>>
>> Section 5.4, next to last paragraph on page 17, last sentence,
>> starting "An Appearance agent does not have to". What does this mean
>> in terms of protocol - is it suppressing a publish, a notify?

It means delaying or suppressing a NOTIFY.

>>
>> Section 5.4, 2nd paragraph page 18 : Is this trying to say use
>> event-rate-control? Or is it modifying the definition of the event package?

We tried to make this vague, as it is something that implementations
will need to manage themselves.  I don't think event-rate-control is
right for this.  Nor is modifying the event package, as the RFC 4235
rules are so vague.

>>
>> Where is there a description of how the joined and replaced dialog xml elements
>> are compared - there's an opportunity for error in implementation if they get
>> the perspective of local and remote tag incorrect - where is the text that describes
>> what to compare these against?

I'll look at Replaces and Join and add in similar text.

>>
>> Section 7.1.1 - is this "0" an example, or is it intended that Single appearance UAs
>> only use "0" and any other values are not allowed? Section 7.1.2 doesn't seem to have
>> the same level of requirements that this section has.

We can make it explicit that one uses only 0, and the other uses 0 and 1 only.

>>
>> Section 7.1.3 - when you say call should be ignored, do you mean requests should be
>> rejected?

Yes, rejected.

>>
>> Should the list starting with "The problems faced by each style" be its own section
>> or is it intended to be part of section 7.1.4?

I'll add a new section.

>>
>> Section 8.2 - You should call out that if enpdoints use end-to-end encryption
>> for their session descriptions, the Appearance agent will not get this information.
>> This and other factors may make the information the appearance agent has imperfect.

Right, I'll note this.

>>
>> Seciton 8.3 - what's the consequence of not rejecting the requests - that exlusive
>> calls get joined?

I'll clarify that the resulting request will be rejected by either the
proxy or UA.  Exclusive calls should not get joined unless the UA is
buggy.

>>
>> Section 9 first paragraph - call out the event package (and that you are probing
>> for support of the extension via the event header parameter).

OK

>>
>> I'm not sure what the second paragraph of section 9 is trying to achieve?
>>

Although there is no such correlation in RFC 3261, many UAs couple the
authentication credentials with the From URI.  RFC 3261 assumes both
registrar and UA are infinitely flexible, a bad assumption in many
cases.  We are calling out this flexibility as a warning to
implementors to avoid issues.  No changes to RFC 3261 are implied by
this, nor are we limiting the uses.

>> Section 10.1 : Do you want to also call out authorizing publishes? Suggest
>> rephrasing to avoid using "the same".

Will do.

>>
>> 10.1 -
>> In general, the examples need to be double-checked for correctness.
>> The request and response in F1, and F2 do not have the same branch-id.
>> F2 should have its expiry on the Contact header field value
>> F5's Subscription-State header does not have the required elements (expires,
>> at least, is required). This occurs in other examples as well.
>> There should be no Event header field in F6.

Right.

>>
>> 10.2 F4 and F21 have the same CSeq and the same partial-notification
>> version number.
>>
>> 10.3 F4 and F6 are from different subscriptions - it's _very unlikely_
>> that the partial notify bodies would have the same version. I need to
>> check, but I think the id attribute to <dialog is also scoped to the subscription.
>>
>> 10.4 F1 : Are you sure about using a partial publish here?
>>
>> 10.9 : Note that Bob's UA is configured not to, not that Bob chooses not
>> to have an appearance number. What normative texts suppresses the normal dialog
>> state change notifications at the end of the paragraph?

There is none.  Probably these NOTIFYs would get sent, although they
are of no use to anyone.

>>
>> 10.13: This is really hard to follow - it might help to tag the subscribes with
>> what's being subscribed to.

OK

>>
>> 10.14 : F48 - How is Alice authoritative for telling the appearance agent that
>> the dialog in that Publish has been terminated?

Alice initiated the pickup with F42.  When F42 fails with a 481 and
Alice decides not to retry, Alice knows the pickup has failed, and
sends F48.

>>
>> 11 - What text precludes a UA from putting in its own appearance number?
>>

Nothing, but this yet another case why a proxy must be able to
delete/modify Alert-Infos that are not correct or come from an
untrusted source.

>> 11 - it would be prudent to reconcile this ABNF change with what SALUD
>> plans to do. We should make it where new parameters can be added with /=
>> after this change.

OK

>>
>> Section 12 - This MUST to authenticate with Digest or S/MIME is stronger
>> than the Replaces spec requires for a generic INVITE/Replaces - were you
>> intending to further restrict the admission policy for INVITES associated
>> with this extension?

No, I'll check the INVITE/Replaces security considerations and make it match.

>>
>>
>> _______________________________________________
>> BLISS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/bliss
>>
>