Subject: RE: [IPORPR] Proposed new IPoRPR charter

From: Albert Herrera <[email-masked]>
Date: Tue, 9 Oct 2001 14:18:34 -0400

Ran,

Thanks for the feedback. The way I see this panning out is that
IPORPR will also act as a focal point for these issues. As
an example, TE has a design team and they need input from 
focal groups such as ours to make sure the right issues are
raised. I have no problem for TEWG taking these on. I just
want to make sure they do.

Albert

> -----Original Message-----
> From: RJ Atkinson [mailto:[email-masked]]
> Sent: Tuesday, October 09, 2001 1:51 PM
> To: [email-masked]
> Subject: RE: [IPORPR] Proposed new IPoRPR charter
> 
> 
> 
> >>> Some, but not all, of the
> >>> specific issues that may need to be addressed are
> >>>   - Packet Encapsulation
> >>>   - Address Mapping
> >>>   - MTU concerns
> >>>   - Multicast and Broadcast
> >>>   - Mapping of Diffserv to any QOS mechanisms developed for 802.17
> >>>   - Network Management
> >>>   - Routing Protocols
> >>>   - MPLS
> >>>   - Traffic Engineering
> 
>         I would delete Albert's proposed new item, MPLS, 
> Traffic Engineering, MTU, and Routing Protocols.  
> 
>         Rationale for my approach is that other IETF WGs already
> exist with charters to do that work.  Moving that work here tends
> to move the work away from the WGs that already have the greatest
> expertise in making those various technologies work over an already 
> diverse set of layer-2 technologies.  IEEE 802.17 will define an
> MTU at layer-2.  Path MTU Discovery exists, is widely deployed,
> and works.  So I don't see any legitimate MTU work for this WG.
> Network Management is overly broad.  SNMP MIBs would be reasonable.
> 
>         Alternatley put, I would leave in the IPoRPR WG only these
> items, some have been edited for clarity of meaning:
>         Packet Encapsulation only if different from Ethernet
>         Address Mapping (IPv4 ARP, IPv6 ND) only if different 
> from Ethernet
>         Multicast/broadcast issues only if 802.17 does not 
>                 support multicast or broadcast at layer-2
>         DiffServ mapping from IPvN to 802.17 QoS only if 802.1p
>                         is not supported by 802.17.
>         Development of SMIv2-compliant MIB for "IP over 802.17"
>                 (Ideally this is joint-development with IEEE 802.17)
> 
>         IFF the other items are dropped by the existing IETF WGs 
> that are chartered for those items, then this WG's charter could 
> always be edited at that point in time to add them.  Having a long
> laundry list of potential work items right now at least causes issues 
> with WG focus.  Note that the "only if" words are quite deliberate.
> Early indications are that *all* of the proposals to 802.17 can just
> work for IP using existing approaches (e.g. used for IP/Ethernet-II).
> 
>         In short, we will likely get lucky and have no work to do.
> 
> Yours,
> 
> Ran
> [email-masked]
> 
> 
> 
> _______________________________________________
> IPORPR mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/iporpr
> 

_______________________________________________
IPORPR mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/iporpr

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 09 Oct 2001 16:22:23 -0400

At 14:18 09/10/01, Albert Herrera wrote:
>IPORPR will also act as a focal point for these issues. 

That is not the way IETF charters usually work.  Moreover,
the words above are NOT in the actual charter text and have
a rather different meaning than the actual charter text that
was posted to the list.

>As an example, TE has a design team and they need input from 

        If they don't undertake it *after* 802.17 has a stable draft 
spec and iff we've got framing and such sorted out and iff there is 
some specific set of things to be undertaken, then we can add that item 
to the IPoRPR charter at that future point in time.

        Charters are living documents; they change from time to time.
One need not get every conceivable item into the charter early on.
The most successful IETF WGs have focused narrow charters, but then
evolve their charter with time as situations require.

        My proposed approach is to have our charter narrowly focused 
on work that is not within scope other places and that is also 
clearly high-priority for this WG.  For example, without a
defined approach to framing, lots of the upper-layer stuff
can't really be addressed anyway.  We can wait and see on the
other items -- certainly wait until after 802.17 has a stable
draft and after we've sorted out framing and the basic issues
at hand.

Ran