Subject: [Manet-dt] IPR Reminder

From: Ian Chakeres <[email-masked]>
Date: Fri, 14 Oct 2005 08:18:30 -0700

Just a reminder about IPR for all those participating. If you know
about any related IPR, please disclose it.

RFC 3979 - <snippet>

2.2.1.  All Contributions
   By submission of a contribution, each person actually submitting the
   contribution is deemed to agree to the following terms and conditions
   on their own behalf, on behalf of the organization (if any) the
   contributor represents and on behalf of the owners of any
   intellectual property rights claimed in the contribution.  Where a
   submission identifies contributors in addition to the contributor(s)
   who provide the actual submission, the actual submitter(s) represent
   that each other named contributor was made aware of and agreed to
   accept the same terms and conditions on their own behalf, on behalf
   of any organization s/he may represent and any known owner of any
   intellectual property rights in the contribution.  This agreement
   must be acknowledged by including in the header of the contribution
   one of the statements in section 3.2 of [IETF SUB].

   A. The contributor represents that he or she has disclosed the
      existence of any intellectual property rights which cover or may
      cover the technology, specifications or standards described in the
      contribution that (1) are owned, controlled or enforceable by the
      contributor or his or her employer, or any affiliate thereof, and
      (2) are reasonably and personally known to the contributor.  The
      contributor does not represent that he or she personally knows of
      all potentially pertinent intellectual property rights owned or
      claimed by the his or her employer (if any) or by third parties.

   B. The contributor represents that there are no limits to the
      contributor's ability to make the grants acknowledgments and
      agreements above that are reasonably and personally known to the
      contributor.

"IETF Contribution": any submission to the IETF intended by the
      Contributor for publication as all or part of an Internet-Draft or
      RFC (except for RFC Editor Contributions described below) and any
      statement made within the context of an IETF activity.  Such
      statements include oral statements in IETF sessions, as well as
      written and electronic communications made at any time or place,
      which are addressed to:

      o  the IETF plenary session,
      o  any IETF working group or portion thereof,
      o  the IESG, or any member thereof on behalf of the IESG,
      o  the IAB or any member thereof on behalf of the IAB,
      o  any IETF mailing list, including the IETF list itself, any
         working group or design team list, or any other list
         functioning under IETF auspices,
      o  the RFC Editor or the Internet-Drafts function (except for RFC
         Editor Contributions described below).

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

---

From: Brian Adamson <[email-masked]>
Date: Mon, 24 Oct 2005 10:06:31 -0400

This is a little bit off-topic, but I have been asked if I can 
provide a _brief_ brief on the wireless network perspective with 
regards to proposed Diffserv Control Plane Elements (DCPEl) at a BOF 
for this initiative on Monday evening of the IETF 64 in Vancouver. 
Later below is a synopsis of the goals so far.

My thoughts with regards to providing them input is to hilite some of 
the unique issues with respect to QoS in MANET (like topology 
dynamics potential for creating bottlenecks, etc and the importance 
of coordinated MAC and IP forwarding layers if QoS support is to 
actually be realized).   Also that the DCPEL design should consider, 
be appropriately modular, etc  so that its messaging, control 
mechanisms, etc (whatever is involved in communicating DiffServ 
control information) could be adapted to alternate transport 
mechanisms and or more ad hoc, potentially dynamic, distributed 
architectures such as might be needed for MANET environments ...

I thought I would pass this info on to the design team here if anyone 
else has opinions or thoughts in this are they would like put forward 
or have me add to a list of MANET issues for this BOF.

best regards,

Brian Adamson
[email-masked]

---------DCPEl OVERVIEW -----------

Diffserv Control Plane Elements (DCPEl) Strawman
information at: [https://www1.ietf.org/mailman/listinfo/dcpel]

Goals:

It's been some time since the Diffserv forwarding path elements were 
standardized. At that time, the approach was to get the mechanisms 
deployed in routers so that approaches to service creation and 
control plane could be attempted. Before closing, the Diffserv WG 
defined the concept of Per-Domain Behaviors (PDBs) in RFC 3086, but 
left the approach to controling PDBs open.

Now Diffserv forwarding elements are available in most routers and 
are in use to create services in some networks. A variety of 
approaches are being used for control and management of Diffserv but 
there appears to be some commonality. A possible path for IETF work 
is to enumerate and classify the common elements and to work toward 
some best common practices. Additionally, it may be useful to present 
specifications for a range of diffserv control plane elements using 
common interfaces.

The major issues to deploying Diffserv-based services are primarily 
operational. The deployment must be cost-effective, be secured 
against vulnerabilities and not become a vehicle for denial of 
service attacks.  Standardization should result in existing toolsets 
being either expanded to cover more needed functionality or to 
interact with other tools. A standardization effort should cover how 
to secure the architecture to mitigate vulnerabilities. Standards for 
a control plane QoS agent for routers may be useful. A desired 
outcome of IETF efforts is to make multiple products available to 
network operators, obviating the time and personnel expense of 
individual solutions. The end goal is to enable more services, both 
for network customers and for control of the network, without taxing 
personnel.

The starting point for a BoF is to look at what's out there, 
determine if there is indeed some uniformity of approach useful as a 
starting point, and determine what's missing.

The intial focus would be the intradomain control plane moving to 
interdomain or AS under same provider and finally to interprovider or 
interoperator.

-- 
Brian
__________________________________
Brian Adamson
<mailto:[email-masked]>