Subject: [Sipping] IETF last call comments on draft-drage-sipping-service-identification

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Mon, 20 Oct 2008 19:42:37 +0200

I have just posted an updated copy of
draft-drage-sipping-service-identification with the partially resolved
comments from the IETF last call (after an extended battle with getting
the referencing to work in xml2rfc).

The comments made, and the changes made, are summarised at:

http://www.softarmor.com/sipping/process/wg-review/reviews/service-id-co
mments.htm

Apart from confirming the validity of my responses to the other comments
there are essentially two comments outstanding:

1)	as to whether the P-Preferred-Service header provides a valid
mechanism with the constraints defined in this document.

2)	as to whether the URN proposed here should be replaced by a
relaxation to use any URN.

I will initiate separate threads on this list to attempt to reach some
conclusion on these comments.

Regards

Keith
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 21 Oct 2008 14:06:15 +0100

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
> Sent: 20 October 2008 18:43
> To: [email-masked]
> Subject: [Sipping] IETF last call comments 
> ondraft-drage-sipping-service-identification
> 
[JRE] The document is certainly inconsistent. In section 1 it states:
"The use of these extensions is only applicable inside an
   administrative domain with previously agreed-upon policies for
   generation, transport and usage of such information."
and then in "In addition, this extension
   allows user agent clients outside the trust domain to provide a hint
   of the requested service."
which, assuming trust domain in this sentence equates to administrative
domain in the first quoted sentence, appears to be in contradiction. All
the stuff do to with P-Preferred-Service seems to be in contradication
to the first quoted sentence.

Then in section 2 it states "The use of these extensions is
   only applicable inside a 'Trust Domain' as defined in Short term
   requirements for Network Asserted Identity (see RFC 3324 [RFC3324])."
which again seems to be contradicated by the P-Preferred-Service parts.

Also the motivation for P-Preferred-Service seems rather weak. How can
it "assist", if the service is derivable from other information in the
request?

It seems to me that P-Preferred-Service does not add any value and
contradicts certain statements in the draft.

John