URN administration in draft-drage-sipping-service-identification-01

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello

On draft-drage-sipping-service-identification-01 I would like to ask
wheter it would be more beneficial to leave out the registration
URN-namespace registration and only point to e.g. RFC 2141.


This would make the draft focusing on the usage of the P-headers, which
I think is fine. The draft would also be flexible and could be used by
other organisations that has their own URN-administration. E.g. OMA
which describes their internal URN-structure in RFC 4358. 3GPP is in the
process of creating a similar draft that can be found as
draft-monrad-sipping-3gpp-urn-namespace.  

As the draft-drage-sipping-service-identification-01 currently desribes
the top-level URN for 3GPP ("3gpp-service" and "3gpp-application"),
URN-administration is as I see it needed anyway for the subservice
identifiers and the application identifiers within 3GPP. Further, OMA
will as I understand it need to either update Keiths draft or write an
OMA-specific draft to include the possible "OMA-service" and
"OMA-application" top level URNs. I do not understand the benefit with
having the top-level URNs handled by IANA as IANA anyway subcontract the
URN administration to other SDOs.

By leaving the URN-administration out,
draft-drage-sipping-service-identification would gain flexibility to be
used by other organisations as OMA without any additions. As the draft
mention POC as a "service" in an example, I would also find it useful
that the draft is flexible enough to also cover OMA.

My comments mainly concerns the introduction and the clauses 4.3, 4.4
and 8, and can be taken into account without much rewording and does not
affect the technical content concerning the definition and usage of
P-Preferred-Service and P-Asserted-Service.

I fully understand and support the need to expedite the handling of this
draft due to 3GPP, but I do not think that this comment will slow down
this process, but rather secure that the draft can be completed timely
with the needed flexibility. 


Thanks

Atle Monrad
Chairman 3GPP CT1

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]