Subject: [NSIS] Update NSIS Charter (v 1.3)

From: [email-masked]
Date: Tue, 6 Nov 2001 16:09:56 +0200

Hi all,

Please find the updated charter.  We recieved some comments from the IESG,
mostly quite positive.  Please let me know what you all think.

Best regards,
John

=========

nsis-charter version 1.3

NSIS
Next Steps in Signaling
Chair:  John Loughney, [email-masked]
Area:   Transport

Mailing List: 
General Discussion: [email-masked] 
To Subscribe: [email-masked] 
In Body: subscribe 
Archive: www.ietf.org/mail-archive/working-groups/nsis/current/maillist.html

Quite a bit of work has been done on Quality of Service and resource
reservation for the Internet.  For a number of reasons, however, there has
not been a significant amount of end-to-end QoS deployed on the Internet
other than best effort service.  

It is noted that resource reservation and traffic engineering can be
considered as part of network administration, and therefore beyond the scope
of the IETF to mandate a particular mechanism.  When considering end-to-end
communication, it is likely that several administrative domains are
traversed.  Interworking between domains in which different QoS solutions
solutions are deployed is problematic. Mobility and roaming additionally add
complexity to the overall picture.  This creates a need for a simplified
solution of signaling QoS, one that reuses parts of existing methods.  This
will allow users to obtain QoS-aware services, irrespective of underlying
mechanisms used.

This working group will develop the requirements, architecture and protocols
for the next IETF steps on signaling QoS. The working group will use
existing IETF signaling as the basis for this work.  Additionally, the
working group will consider how to signal QoS (what sort of QoS parameters
to use), and where to signal (end-to-end, end-to-edge, end-to-proxy,
edge-to-edge, etc.). As input to the working group, the Mobile IP QoS
Requirements document  (draft-mobileip-qos-requirements) will be considered
as one starting point for developing the overall set of requirements.  The
working group will not limit itself to mobile IP-only QoS signaling needs,
however, but will consider general cases of signaling QoS in the Internet
(both wired and wireless). Consideration will be given to the idea of a
building block structure, so the group could develop elements for QoS
signaling that could be modular and be combined with a different payload or
different proxy (e.g.) for use by a non-QoS signaling function. The added
function will be out of scope, but the openness of the design (which may be
a new version of RSVP) will be in scope.

This working group will focus on providing (QoS) signaling function to a
local access network and end-to-end signaling.  It is not the intention of
this working group to invent new signaling protocols. Additionally, mobility
protocols and AAA work are out of scope of the working group.  The work
produced in this Working Group should work with existing IETF mobility and
AAA protocols, including (but not limited to) Mobile IP, SeaMoby Context
Transfer and Diameter.

As with nearly all work being done in the IETF, security is a very important
concern for NSIS.  The working group will study the security requirements
for QoS Signaling, as well as create a threat analysis of QoS signaling.
Compatibility with authentication and authorization mechanisms is also a
concern.  These topics will be addressed in the Signaling Requirements
document.

This working group will provide the framework for interworking with existing
resource allocation methods.  It is a non-goal of the working group to
develop new resource allocation protocols.    

The working group will coordinate with a number of other IETF working
groups, including Diffserv, Seamoby, Mobileip, AAA, Midcom and RAP.  It will
also welcome participation and expression of requirements from non-IETF
standards organization members, for instance 3GPP and 3GPP2 and ITU-T.

Goals and Milestones:
=====================

Jan 01	Initial ID on Signaling Requirements.

Feb  01	Initial ID on Analysis of existing signaling protocols.

Mar 02	Initial ID on 'Framework Signaling Architecture.'

Jun 02 	Submit 'Signaling Requirements' to IESG for publication as an
Informational RFC.

Jun 02 	Initial ID on 'Next Step QoS Signaling'.

Jul 02 	Submit 'Analysis of existing signaling protocols' to IESG for
publication as an Informational RFC.

Sep 02 	Submit 'Framework signaling architecture' to IESG for publication as
an Informational RFC.

Sep 02  	If the initial analysis and framework do not meet two
criteria, submit a rechartering request to the IESG.
The criteria are:  the use of a minimized version of RSVP has been fully
evaluated; the potential of the NSIS work to be a tool box or building piece
for revised or new signaling in non-QoS areas has been covered by the
framework.

Oct 02	If criteria were met, submit 'Next Step QoS Signaling' as a
standards track RFC.

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

---

From: "James Kempf" <[email-masked]>
Date: Tue, 6 Nov 2001 09:28:38 -0800

John,

Great job! Looks just exactly right.

I hope that the WG will discuss initially the reasons why QoS hasn't
been deployed. These have been floating around but I think it will be
important in formulating requirements
to have a clear and well-articulated understanding about why deployment
of QoS has so far been lagging (other than the obvious one that
multimedia traffic on the Internet has yet to become a large part of the
traffic).

        jak

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Tuesday, November 06, 2001 6:09 AM
Subject: Update NSIS Charter (v 1.3)

> Archive:
www.ietf.org/mail-archive/working-groups/nsis/current/maillist.html

---

From: Kireeti Kompella <[email-masked]>
Date: Tue, 6 Nov 2001 10:21:58 -0800 (PST)

Hi John,

> mostly quite positive.  Please let me know what you all think.

Forgive me for jumping into this in midstream; some of my comments
may already have been addressed.

1) Is this "Next Steps in Signaling" or "Next Steps in Signaling QoS"?
2) If the latter, is DiffServ even under consideration?
3) "It is a non-goal of the working group to develop new resource
    allocation protocols."  -- is this a done deed?  (I'm happy with
    it; I just want to know if this has consensus.)

> of the IETF to mandate a particular mechanism.

I'm not sure why this is in here:
a) RSVP is an IETF protocol. 
b) The TE WG is an active IETF WG.
c) "mandate a particular mechanism" -- does the IETF's IDR WG "mandate"
   BGP as an interdomain protocol?  If so, is that bad?  This statement
   seems to question NSIS's raison d'etre.  If we want to go that route,
   NSIS should be a BOF, and we should settle this issue first.

   Personally, I don't agree with the statement, so my choice would be
   to remove it.

Kireeti.

---

From: Xiaoming Fu <[email-masked]>
Date: Wed, 07 Nov 2001 20:21:13 +0100

Hi John,

Looks fine to me. Additionally,

> edge-to-edge, etc.)....

Since the selection of QoS parameters depends on the IS,DS,...x-serv mechanisms
in different domains, I would suggest to add one item into the charter:
develop the mapping rules/interface rules between such x-serv mechanisms and 
the desired QoS signaling protocol/component. 

> AAA protocols, 

How about policy protocols like COPS? Now that it's stated that the resource
allocation mechanisms are admistrative-related and out of the scope of (current)
NSIS, the policy control may be of concern (otherwise whom will this QoS signaling
protocol be going to collaberate with?:)).

> including (but not limited to) Mobile IP, SeaMoby Context
> Transfer and Diameter.

Cheers,

Xiaoming

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 08 Nov 2001 16:19:41 +1100

Hi.
A small nitpick on the wording.

> Archive: www.ietf.org/mail-archive/working-groups/nsis/current/maillist.html
:
<snip> 
> existing IETF signaling as the basis for this work.  Additionally, the

Although the wordings above are not incorrect, it is quite possible they
could be misconstrued.
- You are developing requirements, archiecture and protocols - okay. 
- You will use existing IETF signalling as the basis - surely this
depends on that signalling being suitable for the requirements (and
architecture) you develop. I think it needs some comment about the basis
"where it is feasible and applicable", and that decision would seem to
be within the scope of the WG based on the first sentence.
> :
<snip>
> :
> this working group to invent new signaling protocols. 

Also, the statement that to me could be interpreted as "it is the
intention of the WG _not_ to invent new protocols". Again, I agree with
this direction _as_long_as_ the existing protocols do meet the
requirements (and architecture) that is developed.
/brian