Subject: RE: [Sipping] TISPAN

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 25 May 2005 19:07:06 +0100

I agree clarification is needed in the document, however I am wondering if some of your comments are tending towards duplicating the various ISDN service requirements documents that are referenced within the body of the I-D. With these, there is about 6 - 10 pages of text per service, in material that is already freely and publicly available from ETSI, and duplicating in the I-D would seem to be counterproductive.

As regards the other two comments:

-	SIP is intended to be used for at least one of the users involved in these services.

-	the packages you mention are in the solutions section. I think the solutions section should eventually come out of this draft (possibly sooner rather than later), and therefore as a result the IANA considerations will be correct (by changing things from the opposite direction). As Roland has already said, the solutions but was to give an idea of the way ETSI TISPAN people are currently thinking, and if it sets in progress a discussion of alternative solutions on the SIPPING list, then it has achieved its purpose. Any SIP extensions will be separate documents and progressed in accordance with RFC 3427.

regards

Keith

Keith Drage
Lucent Technologies
[email-masked]
tel: +44 1793 776249

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Dale Worley
> Sent: 25 May 2005 18:00
> To: Sipping (E-mail)
> Subject: [Sipping] TISPAN
> 
> 
> After a first read of 
> draft-jesske-sipping-tispan-requirements, a few points
> come to mind.
> 
> The biggest is that the specific facilities and requirements of each
> simulation service are not spelled out in detail.  And yet, 
> those details
> will be critical in constraining what technological solutions 
> are possible.
> I expect that in the telecom universe, everybody knows exactly what is
> acceptable as a, for example, "terminating indication 
> presentation service",
> but the IP community is unaware of this.  A fuller exposition 
> will help the
> discussion advance faster, and avoid IP people proposing 
> solutions that are
> not acceptable.
> 
> You may want to clarify the context in which you expect these 
> services to be
> used.  Section 4 contains the sentence "The requirements in 
> this document
> are intended to result in a mechanism with general 
> applicability for the NGN
> TISPAN and NOT on the Internet.", which suggests that you are 
> not expecting
> these services to be used anywhere SIP is now used.  If that 
> is so, why are
> you floating this proposal in front of the IETF?
> 
> Section 5 states "This document does not have any 
> implications for IANA.",
> and yet you define (or refer to) two new event packages, "cbbs" and
> "mcid-request-info".  According to RFC 3265 Section 6, event 
> package names
> must be registered with IANA, so these event packages do have IANA
> implications, as does your document.
> 
> Best regards,
> 
> Dale
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.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
> 

_______________________________________________
Sipping mailing list  https://www1.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: "Dale Worley" <[email-masked]>
Date: Wed, 25 May 2005 15:46:37 -0400

> From: Drage, Keith (Keith) [mailto:[email-masked]]
>
> I agree clarification is needed in the document, however I am
> wondering if some of your comments are tending towards
> duplicating the various ISDN service requirements documents
> that are referenced within the body of the I-D. With these,
> there is about 6 - 10 pages of text per service, in material
> that is already freely and publicly available from ETSI, and
> duplicating in the I-D would seem to be counterproductive.

Probably so.  OTOH, it would help if you gave URLs for those documents, as I
don't seem to be able to turn up any copies with Google.

> -	the packages you mention are in the solutions section.
> I think the solutions section should eventually come out of
> this draft (possibly sooner rather than later), and therefore
> as a result the IANA considerations will be correct (by
> changing things from the opposite direction).

That makes sense.  But as this is a requirements document, it would seem
best if your clarifications were edited into the text.

Dale