Subject: Proposed RPS Workgroup Charter Revision

From: Curtis Villamizar <[email-masked]>
Date: Sat, 05 Dec 1998 13:59:19 -0500

RPS Folks,

We (the chairs of this WG) have not been keeping the WG charter up to
date.  The body of the charter doesn't need much change, but the
milestones were terribly out of date.

Cengiz and I have been bouncing around a proposed revised charter
since Chicago.  This really should have gone to the WG quite a while
ago.  We'd like to gather comments on the charter revision at this
meeting and then allow at least a two week period after the WG meeting
to comment before sending the revision to the Area Directors.  I think
the ADs can approve milestone revision and a minor charter revision,
but if the revision is considered a significant change to the charter
they need to bring the revision to the full IESG.

I think the revisions to the body are sufficiently minor that the ADs
can approve.  The former body of the charter was:

    The Routing Policy System Working Group will (1) define a
    language, referred to as Routing Policy Specification Language
    (RPSL), for describing routing policy constraints; (2) define
    a simple and robust distributed registry model for publishing
    routing policy constraints; and (3) define a set of tools for
    analysing registered policy constraints, for checking global
    consistency, for generating router configurations, and for
    diagnosing operational routing problems. It is expected that
    RPSL will enter the standards track.

    The RPSL will be routing protocol independent as well as
    router configuration format independent to support various
    routing protocols such as BGP, IDRP, SDRP, and various router
    technologies. The RPSL will be backward compatible with
    RIPE-181 whenever possible; the registry model will be based
    on the RIPE database.

    The working group will focus on inter-domain routing
    protocols, but will also instigate, review, or (if
    appropriate) produce additional RFCs to support other
    protocols such as multicasting and resource reservation.

A summary of changes are:

  We explicitly are supporting the operations of an existing Internet
  Routing Registry.  This is not a hypothetical routing Policy System.

  We are not defining a set of tools but providing a forum for
  discussion of those tools.  This is a reduction in WG scope as
  defined by the charter, but is more accurate.

  RPSL has already entered the standards track.

  I changed "resource reservation" to "inter-provider quality of
  service".  I think this is also more accurate although no work has
  begun in this area to date.

I appologize for bringing this to the WG mailing list just before the
meeting.  We can still discuss the charter change, but we cannot
decide to take an action at the WG meeting because the proposed
charter, like an internet-draft, must be available well before the
meeting to be considered for advancement (official forwarding it to
the area directors).

If you have comments, please make them before, during, or in the four
weeks following the WG meeting.  I'd like to suggest that we close the
period for comment, Thursday, Jan 7, 1999.  That's four weeks after
the WG meeting (longer than the usual comment period due to holidays).

Curtis

Routing Policy System (rps)
 ---------------------------

 Charter
 Last Modified: ---new-date-here---

 Current Status: Active Working Group

 Chair(s):
     Cengiz Alaettinoglu <[email-masked]>
     Curtis Villamizar <[email-masked]>

 Operations and Management Area Director(s):
     Harald Alvestrand  <[email-masked]>
     Bert Wijnen  <[email-masked]>

 Operations and Management Area Advisor:
     Bert Wijnen  <[email-masked]>

 Mailing Lists:
     General Discussion:[email-masked]
     To Subscribe:      [email-masked]
     Archive:           ftp://ftp.isi.edu/rps

Description of Working Group:

The Routing Policy System Working Group intends to provide
standardization of protocols and recommended practices neccesary to
support interoperability of the Internet Routing Registry (IRR).  The
IRR has been in use since 1995 based initially on the RIPE-181 policy
language.

The activities of the RPS Working Group shall include (1) defining a
language, referred to as Routing Policy Specification Language (RPSL),
for describing routing policy constraints, (2) defining a simple and
robust distributed registry model for publishing routing policy
constraints, and (3) providing a forum for the discussion of of tools
for analysing registered policy constraints, for checking global
consistency, for generating router configurations, and for diagnosing
operational routing problems.

The working group will focus on inter-domain routing protocols, but
will also instigate, review, or (if appropriate) produce additional
RFCs to support other protocols such as multicasting and
inter-provider quality of service.

 Goals and Milestones:

   Ongoing	Review status of RPSL transition and update "RIPE-181
		to RPSL Transition Plan" (rps-transition) as needed.

		Gather feedback on deployment experiences and update
		"Using RPSL in Practice" (rps-appl-rpsl) as needed.

   Dec 1998	Review status of RPSL transition and rps-transition.
		If transition is complete or well into phase 3,
		consider advancing rps-transition.

		Gather feedback on deployment experiences and update
		"Using RPSL in Practice" (rps-appl-rpsl) as needed.

		Review changes to rps-auth and rps-dist resulting from
		comments since Aug 1998 and resulting from
		implementation experieince.

		Discuss need for a separate framework (rps-fw-dist)
		and/or transition document (rps-fw-trans) for rps-auth
		and rps-dist.  Update WG charter according to
		consensus.

		Reissue RPSL as draft and review changes to the
		language resulting from implementation and deployment
		experiences. 

   Spring 1999	Gather feedback on deployment experiences and update
		"Using RPSL in Practice" (rps-appl-rpsl) as needed.
		Consider advancing to informational if there has been
		sufficient deployment experience involving RPSL
		advanced features.

		Review changes to rps-auth, rps-dist (and rps-fw-dist
		and/or rps-fw-trans) resulting from and implementation
		experieince since Dec 1998.

		Reissue RPSL as draft and review changes to the
		language resulting from implementation and deployment
		experiences.  Issue WG last call prior to next
		meeting.

   Summer 1999	Disscuss RPSL WG last call.  Advance to Draft Standard
		or repeat WG last call as needed.

		Review any changes to rps-auth, rps-dist (and
		rps-fw-dist and/or rps-trans-dist) and consider
		advancing as appropriate.

   Fall 1999	Update rps-trans-dist to reflect deployment.

   March 2000	Review need for continuation of WG and close WG if no
		further work is required.

 Internet-Drafts:

  Posted   Revised       I-D Title  <Filename>
  ------   -------   ------------------------------------------
 Mar 1997  Nov 1998  <draft-ietf-rps-transition-02.txt>
		     RIPE-181 to RPSL Transition Plan

 Mar 1997  Jul 1998  <draft-ietf-rps-appl-rpsl-02.txt,.ps>
		     Using RPSL in Practice

 Mar 1998  May 1998  <draft-ietf-rps-auth-01.txt,.ps>
		     Routing Policy System Security

 Sep 1998  Sep 1998  <draft-ietf-rps-dist-00.txt,.ps>
                     Distributed Routing Policy System

 Nov 1998  Nov 1998  <draft-ietf-rps-appl-rpsl-03.txt,.ps>
                     Using RPSL in Practice

 Nov 1998  Nov 1998  <draft-ietf-rps-dbsec-pgp-authent-00.txt>
                     PGP authentication for RIPE database updates

 Nov 1998  Nov 1998  <draft-ietf-rps-rpsl-v2-00.txt,.ps>
                     Routing Policy Specification Language (RPSL)

 Request For Comments:

  RFC  Stat Published       Title
------- -- ----------     -----------------------------------------
RFC2280 PS   Jan 1998     Routing Policy Specification Language (RPSL)

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 06 Dec 1998 08:42:46 -0500

I'll have to read through the charter in detail, but Mike is right:
Changing from a language-defining group to a registry-deployment group
is a major change, and needs IESG approval.

I think (contrary to Mike, perhaps) that an RPS-deployment WG might
be a *good* thing, provided that sufficient buy-in can be demonstrated.

Advertising-wise, I think it's better to do it by closing down this group
and creating a new one; the reasons being:

- It has higher visibility in the community
- It demonstrates comittment to "stop fiddling with the language"
  (this doesn't mean people have to stop creating extensions for usage
  in novel areas, just that the core is declared "stable")
- It allows us to gauge the amount of interest (as opposed to just
  "I started looking at this and never stopped") by seeing who joins
  the mailing list of the new group.

This group would then parallel the MBONED and NGTRANS activities.

RPSD, anyone?

                   Harald

-- 
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

---

From: Mark Prior <[email-masked]>
Date: Tue, 08 Dec 1998 07:57:04 +1030

So do you see the allications document as being part of the existing
charter of this group or part of the charter of the new group?

Mark.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 07 Dec 1998 17:00:44 -0500

>charter of this group or part of the charter of the new group?
Seeing that it looks more like a manual for the IRR than anything else,
it would definitely seem like part of the RPSD WG.
Disclaimer: Only having read partway through it.....

                 Harald

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 09 Dec 1998 12:08:46 -0500

In message <[email-masked]>, Harald Alvestrand writ
> is a major change, and needs IESG approval.

If that is a problem it is quite easy to just not add the first
paragraph.  There were three changes to the body.  The first
paragraph, the reduction of scope by providing a forum for discussion
but not standardizing tools, and replacing a phrase.  If changing the
body is a problem, the body can remain the same.  The work being done
by the WG still fits the original charter.

>   the mailing list of the new group.

This means a BOF at Minnesota rather than a WG meeting.

This might set back progress a bit.  ARIN was planning to deploy a
routing registry in January so timing might not be good.  I'd prefer
not to throw a procedural barrier in the way if there is no good
reason.

Curtis

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 09 Dec 1998 15:50:22 -0500

>not to throw a procedural barrier in the way if there is no good

No reason to have a BOF in Minnesota if we know what WG charter we need.
Let's raise the issue in the meeting.

                         Harald