Subject: RE: [Sipping] new draft-ietf-sipping-isup-05 (tel url dependency)

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 14 Aug 2002 13:18:56 -0500

Just because a Proposed Standard is being revised does not mean, in my
opinion, that all work that relies on the Proposed Standard is suddenly
invalid. I have no idea how long the tel URL revisions will take - some
Internet-Drafts (like sipping-isup-0x, for example) have lives measured in
years, not months. I don't think we need to update this. ENUM, which is
similarly referenced as a optional practice in sipping-isup-05, is also
currently under revision, but I don't think sipping-isup-0x needs to block
until the new ENUM is done, the reference to 2916 is sufficient). Note that
RFC3261 cites and depends on RFC2806 - does that mean RFC3261 is now in need
of revision, or shouldn't be cited, or something? If we were unable to
undertake new work under these conditions, the IETF would never get
anywhere.
 
Your suggestion that we abolish the RECOMMENDED strength level of normative
requirements is noted, and will undoubtedly be given appropriate
consideration.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, August 14, 2002 10:58 AM
To: [email-masked]; [email-masked]
Subject: Re: [Sipping] new draft-ietf-sipping-isup-05

To all, 

The new -05 of sipping-isup does not resolve the comment I submitted on the
IETF Last Call. There does not appear to be any attempt to deal with this
comment. The comment, for those not on the IESG mailing list, was: 

------------------------------------------------ 
Section 11 of this draft references RFC2806 which is currently undergoing a
significant revision (draft-antti-rfc2806bis-05, which is very close to
completion after much discussion). This tel:uri is very important to the
operation of ISUP-to-SIP interworking and can not be ignored, or brushed off
as "informational since it is optional" as reported in the recent meeting.
Its use is very much required to provide the mapping described (in spite of
the use of the word "should"). 

Section 11 must be significantly modified to be in line with the new tel:uri
definition. 
----------------------------------------------- 

(Section 11 is now 12 in -05) 

Instead, a new Section 12.2 was added which appears to further depend on the
old, out-of-date definition of the tel:url in RFC2806. 

The actual text of this new Section 12.2 further confuses the issue by
describing the mapping from SIP to ISUP (e.g., handling of the called party
number) as depending on what the GW has connectivity to, rather than
dependent on where the particular call is routed by the GW. Whether the GW
formats the number in ISUP as "national significant number" or
"international" depends on the requirements of the trunk it routes the call
to. 

I don't understand the extensive use of "SHOULD" in this section (and
others). If it can't be written as "If this occurs, the GW SHALL do that",
then it is useless in defining interworking that is guaranteed to work. 

The requirements to support ISUP to SIP and SIP to ISUP interworking need to
be fully identified so that they can be fed back into the definition of the
tel:uri. These documents can not progess separately. 

Mike Pierce 
Artel

---

From: [email-masked]
Date: Thu, 15 Aug 2002 09:57:52 EDT

In a message dated 8/14/02 2:19:37 PM Eastern Daylight Time, 
[email-masked] writes:

> RFC3261 cites and depends on RFC2806 - does that mean RFC3261 is now in 
> need of revision, or shouldn't be cited, or something? If we were unable to 

When a Proposed Standard is being revised in a way that doesn't drastically 
change it, you are correct. In the case of tel:url, I believe there is 
already an agreement for a significant change, so there should be an 
understanding that RFC2806 is already obsolete and not to be referenced.

A lot of this disagreement is still related to your contention that what is 
being described is an "optional practice" like ENUM. I'm sorry, but 
regardless of the choice of the English word "SHOULD" in the text, what is 
being described is required, if one really wants to complete a pohne call.

I believe what is in this draft would guarantee non-interoperability in the 
future.

Mike Pierce
Artel