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
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
