Subject: [Ieprep] Discussion on Charter

From: "Bose, Pratik" <[email-masked]>
Date: Mon, 21 Feb 2005 17:39:19 -0500

To the IEPREP List Members and WG Chairs, 

In the past few IETFs, there has been a growing movement to standardize
the following capabilities via updates to existing standards or new
internet drafts: 

- Preemption of Inelastic traffic sessions
- Routing and QoS for nested VPNs
- MLPP/GETS capabilities for application protocols like SIP, and
signaling protocols like RSVP
- etc. 

targeting the emergency preparedness of standards based civilian and
military networks. However, there is a no single home for this effort
till date and any activity currently has been following the route of
vetting at IEPREP and then WG acceptance in different WGs (for ex,
SIPPING, TSVWG etc.)

In the interest of various vendors, system integrators (for ex. like my
employer Lockheed Martin), as well as end customers (usually various
governments) who are developing these solutions, it would be efficient
to either recharter IEPREP so that it itself  can standardize such
capabilities or consider the formation of a new WG which can address
this particular area. 

It would be good if we can broach the above topic in mailing list
discussions and at the next WG meeting. 

Thanks, 

Pratik

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

---

From: Ian Brown <[email-masked]>
Date: Wed, 23 Feb 2005 09:48:51 +0000

Pratik - this has been a long-running debate. But it does seem logical 
to have the experts on a particular protocol (the responsible Working 
Group) be involved in any updates that are required to provide these 
capabilities. Given that the WGs conduct the vast majority of their work 
by e-mail, and meet at the physical IETF meetings three times a year, 
would it be particularly more efficient to try to gather all of this 
expertise in one place, whether a rechartered IEPREP or a new WG?

---

From: "Ken Carlberg" <[email-masked]>
Date: Wed, 23 Feb 2005 07:59:26 -0500

Traditionally, the strongest form of persuasion in the IETF is to have an
actual draft-RFC from which others can comment on, and in this case, decide
whether the document is a reasonable starting point to re-charter a group (or
if it should go into another group, remain an individual submission, or simply
expire).

the rare exception that comes to mind is the MANET wg, which recently migrated
its charter from experimental work to proposed standards.  But I doubt that the
exception will change the tradition.  If there are specific draft(s) that you'd
like to put forth that would cover the following, I'd encourage you or others
to submit them.

> signaling protocols like RSVP

cheers,

-ken

---

From: Fred Baker <[email-masked]>
Date: Wed, 23 Feb 2005 15:11:44 -0800

At 09:48 AM 02/23/05 +0000, Ian Brown wrote:
>Pratik - this has been a long-running debate. But it does seem logical to 
>have the experts on a particular protocol (the responsible Working Group) 
>be involved in any updates that are required to provide these 

 From my perspective, it might be.

Related work is going on in a variety of places right now. Some relates to 
RSVP, to MPLS, to diffserv code points, to SIP, and IIRC a few other 
things. The RSVP and diffserv WGs are right now dormant, and the other 
working groups find this rather peripheral to their central foci. If they 
can each severally sit down and get something done, fine. But consider:

  - the SIP work was originally proposed in Adeliade, five years ago
  - the RSVP work builds on work that was finished in 1998, and the WG has
    been closed since then
  - NSIS work, if one chooses that route, is proposed, but at this point very
    sketchy
  - Diffserv has likewise been closed for at least two years
  - We have discussed parts of it with TSVWG, but it is just a few weeks ago
    that they decided to even consider responding to it by allowing the
    documents to become WG drafts

So putting together a WG - whether ieprep with an appropriately changed 
charter or something new - that can focus on this problem and put out a 
solution seems more likely to actually produce a result within our lifetime 
than waiting for WGs that don't exist or don't care to decide it is important.

YMMV

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 23 Feb 2005 18:00:51 -0600

At 07:59 AM 2/23/2005 -0500, Ken Carlberg wrote:
>actual draft-RFC from which others can comment on,

http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-mlpp-that-works-00.txt
covers nearly all of the list below, as well as some other topics, and 
versions of this ID have been around for a year.

;-)

apologies if this seems to be late, as it's late Wednesday and I'm still 
only receiving messages from yesterday from ieft.org (and nothing from the 
23rd yet)

> > signaling protocols like RSVP

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented

---

From: Fred Baker <[email-masked]>
Date: Wed, 23 Feb 2005 15:25:12 -0800

At 07:59 AM 02/23/05 -0500, Ken Carlberg wrote:
>actual draft-RFC from which others can comment on, and in this case, 
>decide whether the document is a reasonable starting point to re-charter a 
>group (or if it should go into another group, remain an individual 
>submission, or simply expire).

Would that be anything like:

   http://www.ietf.org/internet-drafts/draft-baker-nested-vpn-routing-00.txt
   "Routing in a Nested VPN", Fred Baker, 14-Feb-05,
   <draft-baker-nested-vpn-routing-00.txt>

   http://www.ietf.org/internet-drafts/draft-baker-tsvwg-vpn-signaled-preemption-02.txt
   "QoS Signaling in a Nested Virtual Private Network", Fred Baker, 14-Feb-05,
   <draft-baker-tsvwg-vpn-signaled-preemption-02.txt>

   http://www.ietf.org/internet-drafts/draft-chan-tsvwg-diffserv-class-aggr-01.txt
   "Aggregation of DiffServ Service Classes", Kwok Ho Chan, 21-Feb-05,
   <draft-chan-tsvwg-diffserv-class-aggr-01.txt>

   http://www.ietf.org/internet-drafts/draft-ietf-sip-resource-priority-05.txt
   "Communications Resource Priority for the Session Initiation Protocol 
(SIP)",
   Henning Schulzrinne, James Polk, 26-Oct-04,
   <draft-ietf-sip-resource-priority-05.txt>

   http://www.ietf.org/internet-drafts/draft-ietf-sipping-reason-header-for-preemption-02.txt
   "Extending the Session Initiation Protocol Reason Header for Preemption
   Events", James Polk, 25-Aug-04,
   <draft-ietf-sipping-reason-header-for-preemption-02.txt>

   http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-diffserv-service-classes-00.txt
   "Configuration Guidelines for DiffServ Service Classes", Jozef Babiarz,
   14-Feb-05, <draft-ietf-tsvwg-diffserv-service-classes-00.txt>

   http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-mlef-concerns-00.txt
   "MLEF Without Capacity Admission Does Not Satisfy MLPP Requirements", Fred
   Baker, James Polk, 9-Feb-05, <draft-ietf-tsvwg-mlef-concerns-00.txt>

   http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-mlpp-that-works-00.txt
   "Implementing MLPP for Voice and Video in the Internet Protocol Suite", 
Fred
   Baker, James Polk, 8-Feb-05, <draft-ietf-tsvwg-mlpp-that-works-00.txt>

   http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-bw-reduction-00.txt
   "A Resource Reservation Extension for the Reduction of Bandwidth of a
   Reservation Flow", James Polk, Subha Dhesikan, 10-Feb-05,
   <draft-ietf-tsvwg-rsvp-bw-reduction-00.txt>

   http://www.ietf.org/internet-drafts/draft-lefaucheur-rsvp-dste-02.txt
   "Aggregation of RSVP Reservations over MPLS TE/DS-TE Tunnels", Francois Le
   Faucheur, 14-Feb-05, <draft-lefaucheur-rsvp-dste-02.txt>

   http://www.ietf.org/internet-drafts/draft-lefaucheur-rsvp-ipsec-00.txt
   "Aggregate RSVP Reservations for IPsec Tunnels", Francois Le Faucheur,
   14-Feb-05, <draft-lefaucheur-rsvp-ipsec-00.txt>

   http://www.ietf.org/internet-drafts/draft-polk-ieprep-flow-model-considerations-01.txt
   "Considerations for IEPREP Related Protocol Packet Flow Models", James 
Polk,
   16-May-03, <draft-polk-ieprep-flow-model-considerations-01.txt>

Plus my mlpp-policy draft whenever I actually complete it.

?

---

From: "Ken Carlberg" <[email-masked]>
Date: Thu, 24 Feb 2005 01:19:05 -0500

if you'll recall from the original note, the question was whether to re-charter
IEPREP or start a new working group.  by listing the following drafts in
response to my comment, are we to assume that you wish to recharter the IEPREP
group or start a new group?  

>From Pratik's response, its obvious that he had other/your existing work in
mind, but that is a different issue.

-ken

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Fred Baker
> Sent: Wednesday, February 23, 2005 6:25 PM
> To: Ken Carlberg
> Cc: [email-masked]
> Subject: RE: [Ieprep] Discussion on Charter
> 
>    Baker, James Polk, 8-Feb-05, 
> <draft-ietf-tsvwg-mlpp-that-works-00.txt>
> 
>

---

From: Fred Baker <[email-masked]>
Date: Wed, 23 Feb 2005 22:51:54 -0800

>group or start a new group?

personally, I don't care. From my perspective, either gives us a way 
forward, and that's what I'm looking for.

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 24 Feb 2005 09:47:40 -0600

ieprep (currently) is not meeting according to the draft agenda at
http://www.ietf.org/meetings/agenda_62.txt
so discussing this will have to be on the list and/or hallway conversations.

I think there's sufficient interest from a good portion of the ieprep WG 
participants to work on a government-side set of solutions (vs. the current 
"public-only" solution side), which include extensions to existing 
protocols. Scott's position has always been to develop requirements from 
the IEPREP WG, and have the protocol WGs develop the actual standards. 
Well, that sounded great then, but it hasn't been working out that way (see 
Fred's note).

I think there has been considerable resistance since Pittsburgh from the 
chairs and the IESG to have a government network focused area of work in 
this (or any other) WG.

With the above in mind, there really hasn't been a forum (WG) to take an 
extension to RSVP or Diffserv to, so each extension has been waffling since 
initial submission until now. This is clearly not efficient, and it 
obviously not getting vendors anywhere wrt solving customer requirements 
for solutions they want to buy.

cheers,
James

                                *******************

---

From: Rex Buddenberg <[email-masked]>
Date: Thu, 24 Feb 2005 09:35:15 -0800

More on Fred's astute comments.

A lot of the QoS issues -- which seem to take up a good share of the ink
-- are layer 2 issues.  That puts them outside the scope of IETF as a
whole as layer 1/2 standards are not addressed by IETF (a decision, btw,
that I agree with).  

For example, if you want GETS type service, one translation is a need
for assured access at layer 2.  With contention queues (like 802.11
WiFi), you simply can't get that.  And nothing you do at layer 3 and up
will change that fact.  If, on the other hand, you have a scheduling
queue (802.16, .20, .22), you can provide layer 2 QoS.  At this point,
we do have an issue -- how do you control that stuff from higher layers.
Here the otherwise-healthy division between IETF and IEEE needs a
connection.  This need has been often recognized but never really hit
stride ... perhaps when WiMax stuff arrives in the marketplace in force
that will change (why build a control mechanism when there's nothing to
control?).

-- 
b