Subject: [BLISS] Feedback: Problem Statement

From: Shida Schubert <[email-masked]>
Date: Wed, 28 Nov 2007 16:42:33 -0800

From our experience tackling the automatic call handling, and through
talk we had with people interested in contributing to the existing 
milestones,
we realized a need to change few things in the problem statement.

 We are going to be discussing this at the meeting next week, during the
time slot we assigned for Jonathan..

1. Defining a feature group --------------------------------
  Currently BLISS Solution Framework proposes the WG
  to identify a set of features(feature group) which have been known to 
have
  interoperability problems that are likely to share common source of 
problems.

 Issue: If there is a feature with real problem out there in the wild, 
this may hinder
      the work from progressing, simply due to it being the only feature 
of its kind,
      with no other feature with commonality.

 Proposal: Text in this phase can be a bit more lenient,
      so a single feature/service with a known problem can be brought
      in and worked upon, rather than wasting the time searching
      for other features sharing the common problems/characteristics to
      be considered.

2. Submit Feature Flow -----------------------------------------
  Currently BLISS Solution Framework asks to collect flows or
  explanatory text that articulates the logic specific to the feature
  for each of the components involved.

 Issue:  For milestone such as ACH, Call-Completion and even possibly
      call-park/pickup the baseline technologies may differ dramatically,
      and looking and comparing call-flows may mean little or nothing, as
      problem reside somewhere else where SIP is not involved.

       On the other hand, when the problem is apparent and
      specification used to satisfy the baseline requirements are the same
      across products that are suffering from interoperability problems,
      closer look at the call-flow may be necessary.

 Proposal: Allow for alternative approach for collecting information about
      the "feature"/"feature group", whether it be simple 
questions/answers, list of
      supported specs and call-flow etc. 

3. Scoping the functional primitives/deliverables -----------------------

  The functional primitive as defined in phase 1 merely works as a 
filter to
find other feature that may fit in the feature group.

 For ACH, the functional primitives in Phase 1 may have been

 "features that result in a retargeting or response operation that 
depend on
   user-specified criteria"

 as documented in the problem statement.

 Though when we get to phase 3, there may be multitudes of issues
associated with the interoperability problems, each of which may have
applicability elsewhere. For ACH it may be..
 
  1. Lacking common configuration method.
  2. Inconsistency in status code used for signaling certain state.
  3. Lack of mechanism to inform the client of the current ACH settings.

 Now are each of these a potential functional primitive therefore 
separate deliverable?
If we want to re-use whatever we define whether it be some sort of 
standard or BCP,
then the answer may be yes, but we then face the dilemma of not having 
the ability to
satisfy what's defined in the section 6 of the problem statement.

 "It is important that the feature group be well articulated in the 
title, so that implementors
   seeking guidance on these features can find it."

 Current recommendation for the deliverable in section 6 seems to lack 
the flexibility. There
needs to be some room for BLISS to define a deliverable at smaller scope 
(e.g. BCP
for sharing configuration status between UA and Proxy), which may then 
be referenced by
another document named "features that result in a retargeting or 
response operation
that depend on user-specified criteria".

 Any thoughts?

Regards
Shida       

_______________________________________________
BLISS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bliss