Subject: RE: [NSIS] QSPEC Issue: Inclusion of H.460.4/H.323 Priority Parameters

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Wed, 14 Sep 2005 14:28:06 -0400

Hi, Jerry and all:

Per IETF perspective, let us keep our focus on IETF application like
SIP. SIP will have different perspective in standardizing the priority
parameters. Let us wait for completion of the present SIP works on
priority. 

So, we do not need to focus on non-IETF legacy applications to support
their needs for now. No need to over burden the present spec as Henning
indicated.

Best regards,
Radhika

PS: Other drafts can be written for taking care of interoperability
between IETF and non-IETF applications in using NSIS QOS signaling
schemes.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ash, Gerald R (Jerry), ALABS
Sent: Wednesday, September 14, 2005 1:39 PM
To: [email-masked]
Cc: Ash, Gerald R (Jerry), ALABS
Subject: [NSIS] QSPEC Issue: Inclusion of H.460.4/H.323 Priority
Parameters

Hi All,

Ken Carlberg suggested in
http://www1.ietf.org/mail-archive/web/nsis/current/msg05274.html that
H.460.4/H.323 call priority elements be added as another priority
parameter in the QSPEC draft
(http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-05.txt). 

In response, I suggested a possible mapping in
http://www1.ietf.org/mail-archive/web/nsis/current/msg05284.html.

An Nguyen voiced support in
http://www1.ietf.org/mail-archive/web/nsis/current/msg05290.html. 

To determine consensus regarding adding the H.460.4/H.323 priority
parameters, John suggested to post the pros and cons to the list, and
people can express their opinions on to whether to include these
parameters or not.

On the pro side:

1. Ken Carlberg: 'Microsoft's use of H.323 for its Netmeeting software,
as well as Cisco's support for H.323 (in the form of gatekeeper's and
the like), would seem to give some substantial weight to the protocol --
enough so that its not just a paper-only specification. Over time, SIP
may take over, but I think that kind of speculation would be outside the
scope of this working group.'
2. An Nguyen: 'From an interoperability perspective, we want hooks in
the NSIS signaling architecture so that H.323 can still be supported.
And interoperability is one of our 14 requirements.'

On the con side:

1. H.323 is a legacy technology (several have expressed this concern).
2. Cornelia brought up the issue at the IETF-63 NSIS meeting, where:
a. Henning Schulzrinne expressed the opinion to not include such legacy
parameters: 'do we need the H.460.4/H.323 elements; deployment is going
down rather than up; could they define these later? there is always one
more.'
b. Cornelia related that 'the general mood (at IETF-63) was to not
include even more parameter values in the QSPEC.'

Please express your opinion RE including the H.460.4/H.323 priority
parameters in the QSPEC I-D, so consensus can be determined for or
against.

Thanks,
Regards,
Jerry

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: David R Oran <[email-masked]>
Date: Wed, 14 Sep 2005 14:38:04 -0400

Frankly, it strikes me as strange at best to import ANY specific  
application-level priority/preemption parameters directly into NSIS.  
What about SAP (business applications) for year-end-closings? or  
flows set up by RTSP? We really want the World-cup finals to not be  
messed up, right?!

What happened to layered architecture?

Cheers, Dave.