headers
Henning Schulzrinne | 1 Oct 2002 01:58

Re: IEPREP SIP REQ-1 to REQ-5

General remark: finding reasonable compromise between being unduly 
specific and uselessly vague is hard. Thus, concrete wording suggestions 
are always appreciated.

>         REQ-2: Independent of particular network architecture: The
>              mechanism should work in the widest variety of SIP-based
>              systems. It should not be restricted to particular
>              operators or types of networks, such as wireless networks
>              or protocol profiles and dialects in certain types of
>              networks.
> 
> How would one know if a proposed solution met REQ-2?  If not restricted to
> particular operators or types of networks, does it mean it should work for
> all?

While you probably can't prove that something can work in every single 
network that anybody could ever dream up, you will definitely know when 
REQ-2 is *not* met. Without naming names, this is meant to ensure, for 
example, that there is no 3GPP-specific or PacketCable-specific 
solution. (Both organizations use SIP, with extensions, in their 
respective architectures, for 3G wireless and cable modems.)

> 
> The document lists 4 network models and 4 hybrid networks (or topologies).
> Does "network architecture" refer to these previously introduced items?

No, it refers to the protocol profiles and extensions mentioned in the 
paragraph.

>         REQ-3: Invisible to IP network: It should be possible to use the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Henning Schulzrinne | 1 Oct 2002 02:15

Re: IEPREP SIP REQ-6 to REQ-10


>         REQ-9: Default behavior: Network terminals configured to use
>              priority scheme may occasionally end up making calls in a
>              network that does not support such a scheme or the terminal
>              may have an older list of priorities in a namespace. In
>              those cases, the protocol must support a sensible default
>              behavior that maximizes the chance for call completion
>              without compromising network integrity.
> 
> What is a sensible default behavior that maximizes the chance for call
> completion under circumstances where networks or terminals don't understand
> the scheme or have outdated information?  Is regular SIP default call setup
> an acceptable solution?  If not, does someone have an example solution of
> something satisfying the above requirement?

Yes, regular SIP default would be. Maybe saying this explicitly would 
help :-)

Translated, this means if you use a priority label that the network 
can't grok, the caller should be no worse off than if you had used no 
label. New wording suggestion:

"Network terminals configured to use a
priority scheme may occasionally end up making calls in a network that
does not support such a scheme.  In those cases, the protocol must
support a sensible default behavior that treats the call no worse than a
call that did not invoke the priority scheme."

>         REQ-10: Address-neutral: The mechanism cannot rely on
>              identifying a set of destination addresses or URI schemes.
(Continue reading)

Permalink | Reply | 0 comments |
headers
King, Kimberly S. | 1 Oct 2002 18:07
Picon
Favicon

RE: IEPREP SIP REQ-10 (w/14)


> > Does REQ-10, taken along with  REQ-14, say all network elements must
> > understand the mechanism (at least enough to provide a list 
> of supported
> > name spaces or enough to be tell the name space is not supported)?
> 
> Not really. It could just mean that one should be able to 
> find out if a 
> network element supports any scheme. If the network element doesn't 
> support the scheme at all, it can return the protocol equivalent of 
> "Huh?", without having a clue whether this was a feature asking for 
> priority treatment or a Big Mac.
> 

What happens if I ask for a Big Mac feature today?  Do all network elements
return the protocol equivalent of "Huh?" or does this reflect a modification
of all network elements?
Permalink | Reply | 501 comments |
headers
Henning Schulzrinne | 1 Oct 2002 18:15

Re: IEPREP SIP REQ-10 (w/14)


> What happens if I ask for a Big Mac feature today?  Do all network elements
> return the protocol equivalent of "Huh?" or does this reflect a modification
> of all network elements?

To be concrete: One way to ask for a feature in SIP is via the Require 
header, as in (many details elided)

INVITE sip:alice <at> burgerking.com SIP/2.0
Require: BigMac

would return the status response

SIP/2.0 420 Bad Extension
Unsupported: BigMac

(Methods would be requested via OPTIONS and returned in Allow, but 
that's not likely to be applicable in our application.) All SIP systems 
have to support this mechanism today, as it is the foundation of the 
feature negotiation mechanism.

Henning
Permalink | Reply | 501 comments |
headers
Henning Schulzrinne | 1 Oct 2002 20:42

Re: requirements document(s) to SIPPING

> 
> 1. Preserve any priority scheme in the CSN when applying SIP bridging
> 
> This would prevent loss of information in the CSN.  It might also make sense
> to limit this case to where both CSN's use the same priority scheme (e.g.,
> suppose CSN 1 is employing MLPP.  Then MLPP information is presented in full
> to CSN 2 but there is no attempt in the IP network to translate MLPP into a
> different priority scheme).
> 
> Question for WG:  Can this be done with existing RFCs or new drafts?  Are
> there any specific security or other requirements in this case?

I believe this can be done with existing drafts, such as the R-P 
document. It could also be done with ISUP bridging, but that assumes 
that both sides use ISUP and the same version of it. RFC 3372 describes 
this architecture in some detail.

> 
> 2. Introduce priority scheme at SIP endpoints (e.g., SIP user agents,
> gateways, media servers).
> 
> This would allow new optional functionality such as providing emergency
> users preferred access to gateway or media server resources, allowing
> preemption to occur at endpoints, etc.  This option increases complexity and
> has security issues that will also need to be addressed.

I believe the security issues aren't all that different than those we 
already face - you need to prevent unauthorized access. I don't see how 
this increases protocol complexity. It may increase implementation 
complexity slightly, but many existing media systems already have
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rex Buddenberg | 1 Oct 2002 21:34
Picon

Fwd: [CAP] CAP input demo / update


No, this isn't VoIP and SIP so tune it out if that's where your head is.  But 
it is emergency services use of the Internet.

----------  Forwarded Message  ----------

Subject: [CAP] CAP input demo / update
Date: Tue, 1 Oct 2002 12:02:47 -0700
From: Art Botterell <acb <at> incident.com>
To: CAP-list <at> incident.com

[sorry if this is a duplicate... having a bit of trouble with the
listserver today!]

Friends -

As you know, we're demonstrating some applications of the current
draft alert message format in Northern Virginia, under the auspices
of the ComCARE Alliance.  As part of that demo we've posted an input
form, with a "pop-up" graphic tool for drawing affected-area
polygons, that renders an alert message and passes it off to various
processors.

Please feel free to play with it for the next few days... after that
we'll need to restrict it to actual demo use, at least for awhile.
The input tool is at
<http://www.incident.com/cap/svdemo/svdemo.html>... it works best on
Internet Explorer on Windows.

If you fill out the form and submit it, you'll see the XML format
(Continue reading)

Permalink | Reply | 0 comments |
headers
King, Kimberly S. | 1 Oct 2002 21:47
Picon
Favicon

RE: requirements document(s) to SIPPING


> > 
> > 2. Introduce priority scheme at SIP endpoints (e.g., SIP 
> user agents,
> > gateways, media servers).
> > 
> > This would allow new optional functionality such as 
> providing emergency
> > users preferred access to gateway or media server 
> resources, allowing
> > preemption to occur at endpoints, etc.  This option 
> increases complexity and
> > has security issues that will also need to be addressed.
> 
> I believe the security issues aren't all that different than those we 
> already face - you need to prevent unauthorized access. 

I'm glad to hear you say that.  I wasn't sure how to read some of the
security requirements.  

"SEC-1: More rigorous: Prioritized access to network and end
             system resources imposes particularly stringent
             requirements on authentication and authorization mechanisms
             since access to prioritized resources may impact overall
             system stability and performance, not just result in theft
             of, say, a single phone call."

Part of this process is just understanding what is being said.

> don't see how
(Continue reading)

Permalink | Reply | 1 comment |
headers
Henning Schulzrinne | 1 Oct 2002 22:09

Re: draft-ietf-ieprep-sip-reqs-00.txt


Mpierce1 <at> aol.com wrote:
> Comments on draft-ietf-ieprep-sip-reqs-00:
> 
> 2. Instead of CN for the abbreviation, I would suggest SCN (Switched 
> Circuit Network).

Well, Kimberly used CSN. From a quick Google search, both terms seem to 
be in use. I don't much care either way...

> 4. End of section again refers to four resources (gateway, CN, IP 
> network resources, and receiver). The text in Section 3 also defined SIP 
> proxy resources.
> 

I added proxy with (x).

> The meaning of the (x) in the table is not clear. For example, although 
> it says that (x) means the resource is in the CN, the first row in the 
> table which is the IP-only case has an (x).

The "as the ..." part is too narrow; I just dropped it.

> 
> REQ-1 implies that the U.S. defense network priority scheme is different 
> than Q.735. It is identical. NATO requirements (also five levels) are 
> also the same.

Reworded as
(Continue reading)

Permalink | Reply | 501 comments |
headers
Henning Schulzrinne | 1 Oct 2002 22:16

Re: requirements document(s) to SIPPING

> I'm glad to hear you say that.  I wasn't sure how to read some of the
> security requirements.  
> 
> "SEC-1: More rigorous: Prioritized access to network and end
>              system resources imposes particularly stringent
>              requirements on authentication and authorization mechanisms
>              since access to prioritized resources may impact overall
>              system stability and performance, not just result in theft
>              of, say, a single phone call."

I added a more explicit reference to the resource mentioned earlier. 
SEC-1 applies to all of them. (I'm not sure if that's where the 
confusion came from.)

> The case of endpoint prioritization is an important case that we should
> address.  Sure, the above pseudo code is trivial and represents a policy
> saying high priority can starve everything else (assuming you want this in a
> loop).  That's one policy.  It's fine that this is trivial after working out
> the requirements but part of the complexity is figuring out the
> requirements.  

I don't think we need to specify a particular queueing policy. I'm a bit 
lost as to what impact on requirements this might have. (I can't see any 
new ones.)

> The purpose of the exchange was to focus on underlying assumptions and
> requirements so we can provide a good requirements document for SIP/SIPPING
> that meets the needs of the ieprep community.
> 
Thanks for all your close reading and comments.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Henning Schulzrinne | 1 Oct 2002 22:23

Re: (no subject)


> the above may need a bit of clarification. I think one could argue that 
> a specific NameSpace represents a "particular priority mechanism".

I will formulate a bit more positively.

> 
> I can gather that what you are saying is that the NameSpace should not
> reflect a specific organization or implementation.  And you also want to
> avoid a one-to-one correlation between a namespace and geographic/geo-
> political boundaries.  thats fine.

Indeed.

> 
> one the other hand, I assume that NameSpace(s) that correlate to a
> standard like MLPP (from ITU) would be fine.  valid interpretation?
> 
> also, would it be fine to state that private or experimental NameSpace(s) 
> could be defined, but they simply would not be registered with IANA.  We
> kind of have that with the current diff-serv allocation of code points.
> The one difference with the diff-serv analogy is that I do NOT think there
> will be a need to additional parameter stating whether the NameSpace is
> public or private.  if the NameSpace is not one listed by IANA, then by
> default its private.

Yes; noted.
Permalink | Reply | 565 comments |

Gmane