[Gen-art] Re: gen-art review of draft-camarillo-sipping-profile-key-01.txt

Hi Scott,

you are right; the second requirement could have been phrased in a more
general way. We could perform the following change:

OLD:
     2.  It is necessary to avoid storing individual Public Service
         Identities matching a Wildcarded Public Service Identity in the
         user database.
NEW:
     2.  It is necessary to keep the user database's size and maintenance
         manageable (e.g., storing individual Public Service
         Identities matching a Wildcarded Public Service Identity in the
         user database is not believed to be an acceptable solution).

> Second, a question.  "The I-CSCF inserts the P-Profile-Key header 
> field into a SIP request and the S-CSCF removes it before routing the
>  request further."  Does an S-CSCF ever forward a request to another 
> S-CSCF?

Not to an S-CSCF within the same network. That is, not to a S-CSCF that
will need to access the same user database as the S-CSCF currently
handing the request.

Thanks for your comments,

Gonzalo

Scott W Brim wrote:
> Bottom line: OK with nits.
> 
> I have no objection to the technical content of this draft going 
> forward, but here are a couple of notes on the descriptive text.  I 
> don't expect them to result in any changes.  They are just for the
> future.
> 
> First, not unusual imported requirements, it makes a solution into a 
> requirement, which I believe should be controlled.  The derived 
> requirements are:
> 
> 1.  It is necessary to optimize the response time for session 
> establishment in the 3GPP IMS. 2.  It is necessary to avoid storing
> individual Public Service Identities matching a Wildcarded Public
> Service Identity in the user database.
> 
> IMHO from the point of view of the IETF, the second requirement isn't
>  a requirement, it's a solution.  The requirement is probably
> something like keeping database size and maintenance manageable.  How
> to meet that requirement will vary, and in some cases a large
> database may be fine.  I don't like instituting solutions as
> requirements, because down the road that causes problems.
> 
> Second, a question.  "The I-CSCF inserts the P-Profile-Key header 
> field into a SIP request and the S-CSCF removes it before routing the
>  request further."  Does an S-CSCF ever forward a request to another 
> S-CSCF?
> 
> Thanks ... Scott

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art