Subject: [Gen-art] RE: Latest updates : draft-ietf-l2tpext-pwe3-ethernet-08.txt

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Sun, 6 Aug 2006 14:25:37 +0300

I am happy with the text that addresses my DISCUSS, but I suggest that
IEEE 802.3, IEEE 802.1Q and IEEE802.1ad be included as Normative
References. 
 
Dan

  _____  

	From: Maria A. Dos Santos (mariados) [mailto:[email-masked]]

	Sent: Friday, August 04, 2006 10:03 PM
	To: [email-masked]; [email-masked]; [email-masked];
[email-masked]; Jari Arkko; Cullen Jennings (fluffy); Mark
Townsley (townsley); Romascanu, Dan (Dan)
	Subject: Latest updates :
draft-ietf-l2tpext-pwe3-ethernet-08.txt

	Hi all,
	 
	The following is the consolidated list of all the LC comments
and responses
	by different people.  I highlighted the responses and what/how
will be replaced.
	This has been reviewed by Ignacio Goyret once already and I
already 
	incorporated his last batch of editorial change requests in the
attached
	version 8 of the draft.
	 
	There is still one comment from Cullen Jennings which is not
resolved
	yet, but no response from Cullen yet.  Do others want to advice
on how
	to handle this comment?
	 
	regards,
	Alice

------------------------------------------------------------------------
-------------------------------------
	
	###
	Comments raised by Francis Dupont, with additional comments/
	responses inserted by Brian Carpenter, Mark Townsley and 
	Ignacio Goyret.
	 
	 - Abstract: This document describes transport -> the transport?
	 
	Fixed
	 
	 - 1.1: remove trailing "." of PE definition
	 
	Fixed
	 
	 - 1.1: I suggest to introduce here the L2TPv3 messages as
	   imported abbreviations in the logical (i.e., not alpha)
order.
	 
	Added section 1.2 to introduce the l2tp message types
	 
	 - 1.2 (NSP function): Ethernet packets -> Ethernet frames
	 
	Fixed
	 
	 - 1.2: as VLAN tags are in some further cases 802.1q tags,
	   I propose to cite 802.1Q the first time and use "VLAN"
everywhere
	   at the exception of 802.1Q specific places.
	 
	Inserted elaboration for terms such as "Ethernet" and "VLAN" in 
	Introduction section.
	 
	 - 2.2 c): must -> MUST?
	 
	Fixed
	 
	 - 2.3.2: to indicate the Ethernet interface -> plural without
"the"?
	 
	Fixed
	 
	 - 3.2: may -> MAY?
	 
	Fixed
	 
	 - (technical) 3.3: I am not convinced at all by the very last
part
	   (fragmentation/reassemble recommendation) because it is a
layer violation
	   and the goal (manage the issue at only one place as explain
in
	   L2TPFRAG section 5.1) is not explained.
	 
	Replacement suggested by Mark Townsley.
	 
	   "As a result, the pseudowire endpoints SHOULD support
	    Fragmentation and Reassembly procedures specified in Section
5 of
	    [L2TPFRAG] or section 4.1.4 of [RFC3931] when the Ethernet
payload 
	    is IPv4.  Only one of these methods SHOULD be used for a
given 
	    Ethernet PW."
	 
	has been changed to:
	 
	   This is not specific only to Ethernet over L2TPv3,
	   and the base L2TPv3 specification [RFC3931] provides general
	   recommendations with respect to fragmentation and reassembly
in
	   section 4.1.4. "PWE3 Fragmentation and Reassembly" [L2TPFRAG]
	   expounds on this topic further, including a fragmentation and
	   reassembly mechanism within L2TP itself in the event that no
other
	   option is available.  Implementations MUST follow these
guidelines
	   with respect to Fragmentation and reassembly.

	 - 4: please introduce the AC abbrev
	 
	Fixed
	 
	 - 4: the 802.1Q tag -> a VLAN tag
	 
	Fixed
	 
	 - 4: preamble or FCS -> preamble and FCS
	 
	Fixed
	 
	 - 4: IPSec -> IPsec (cf RFC 4301 introduction)
	 
	Fixed
	 
	 - 4: For Ethernet VLAN PW, VLAN tag rewrite ...: can't parse
this statement

	Replacement proposed by Mark Townsley:
	 
	  While architecturally [RFC3985] outside the scope of the
L2TPv3 PW 
	  itself, if VLAN tags are present, the NSP may rewrite VLAN
tags on 
	  ingress or egress from the PW (see section 3.1)."
	 
	Replacement proposed by Brian Carpenter:
	 
	  The VLAN tags of an Ethernet VLAN PW may be rewritten by NSP
at
	  the egress LCCE, which is outside the scope of this document
(see
	  Section 3.1).
	 
	Mark's suggestion is incorporated into draft.

	 - 4: there is no TOS octet or QoS field in the IP header (look
at RFC 2474?)

	Mark Townsley:
	 
	  > No doubt. We need to at a minimum change this to "ToS
bits"and strike 
	  > "IP QoS field" - the paragraph should perhaps simply be
rewritten to 
	  > refer to DSCP only.

	Exchanges between Brian and Ignacio:
	 
	  >>>[BC] Indeed, there is no "for example" about it; there only
the DSCP.
	  >> 
	  >> 
	  >> RFC2474 specifically refers to that byte as "the TOS octet"
(eg, see 
	  >> the second to last paragraph on the abstract, page 2).
	  >> 
	  >> How about eliminating the parenthesized "for example,
according to DSCP"?
	  >> Would that be sufficient?
	  >
	  >Well, it is called the TOS octet in IPv4 and the Traffic
Class octet in
	  >IPv6 - the only phrase that applies to both is DSCP. So
either you have 
	  >to put "TOS or Traffic Class octet" or refer to 2474, I
think.

	Changed reference to "DS field" and added reference to RFC2474.

	 - 4: 802.1Q CS and ... -> too many "and" (note that here 802.1Q
is the
	   right term)
	 
	Fixed
	 
	 5: should -> SHOULD ??
	 
	From Mark:
	 
	  I'm not entirely convinced that this is a SHOULD given that it
isn't 
	  really a protocol mechanism that we are defining here, but a 
	  deployment recommendation.
	 
	So this stays unchanged.

	 9.1 L2TPFRAG: missing I-D name
(draft-ietf-pwe3-fragmentation-10.txt?)
	 
	Fixed

########################################################################
###
	*Lars Eggert:*
	*Discuss:*
	*[2006-06-30]* Section 5., paragraph 3:
	 
	 >    LCCEs SHOULD monitor for congestion (by using explicit
congestion
	 >    notification, or by measuring packet loss) in order to
ensure that
	 >    the service using the Ethernet or Ethernet VLAN PW may be
maintained.
	 >    When severe congestion is detected (for example when
enabling
	 >    Sequencing and detecting that the packet loss is higher
than a
	 >    threshold) the Ethernet or Ethernet VLAN PW SHOULD be
halted by
	 >    tearing down the L2TP session via a CDN message.  The PW
may be
	 >    restarted by manual intervention, or by automatic means
after an
	 >    appropriate waiting time.  Note that the thresholds and
time periods
	 >    for shutdown and possible automatic recovery need to be
carefully
	 >    configured. This is necessary to avoid loss of service due
to
	 >    temporary congestion, and to prevent oscillation between
the
	 >    congested and halted states.
	 
	  RFC3985 also says: "Where congestion is avoided by shutting
down a PW,
	  a suitable mechanism must be provided to prevent it from
immediately
	  returning to service and causing a series of congestion
pulses." I
	  don't see such a mechanism in this draft, only the above
	  acknowledgment of the issue and the recommendation of careful
	  configuration.
	 
	  (This is identical to the DISCUSS I have raised
	  against draft-ietf-pwe3-atm-encap. As far as I know, PWE3 is
working
	  on an approach for addressing this. This document, however,
belongs to
	  a different WG, so I'm not sure if any resolution that PWE3
comes up
	  with would apply to this document as well. I'd hope that it
would -
	  can the authors/ADs confirm?)
	 
	Confirmed by Stewart Bryant and Mark Townsley that the PWE3
congestion work 
	would be general and applicable to both L2TP and 
	MPLS based Pseudowires.

########################################################################
###
	*Cullen Jennings:*
	*Discuss:*
	   *[2006-07-05]* I may not understand the congestion control
technique but 
	   it looks like it says,  "in case of congestion, pull the
plug". I don't 
	   believe anyone will implement this congestion control
suggestions - and 
	   if they do, I don't believe the resulting systems will be
usable - they 
	   will be impossible to manage not to mention the incredible
DOS 
	   opportunities. No advice on the threshold is provided. I
think this 
	   needs to be updated to either be clear no congestion control
is provided.
	 
	From what I understand, the draft is inline with the current
state of congestion
	control for emulation technologies, and PWE3 WG is currently
conducting 
	further study on the topic.  Once we get the result of that,
this draft
	and all other pwe drafts (both l2tp and mpls) will leverage from
that
	mechanism.  So at this point, the goal of the "Congestion
Control" section 
	in this draft is only to emphasize the possibility of congestion
and provide
	some general best-effort recovery mechanisms.  Would it be
better if I emphasize
	the goal?
	 
	I am not sure what general default threshold is appropriate
given that the threshold will
	vary according to network size and average traffic load of
individual network.  That's why
	it is left undefined and left to administrator to experiment.
	 
	   The section titled "Applicability Statement" gives me no idea
where this 
	   is applicable and where it is not.
	 
	Would you mind elaborating what information are you expecting
here?

########################################################################
###
	*Dan Romascanu:*
	*Discuss:*
	*[2006-07-03]* I made the following two comments during the IESG
LC. The 
	comments were not addressed:
	 
	1. The I-D speaks about 'Ethernet' but does not provide any
reference.
	What version of the Ethernet standard is targeted here? The
latest 
	approved version of the Ethernet standard is IEEE Std
802.3-2005, but 
	the IEEE 802.3 WG also has in works an extension of the frame
size as 
	IEEE 802.3as. One cannot talk about Ethernet PDU and MTU without
a 
	proper reference.
	 
	2. The I-D speaks about 'Ethernet VLAN'. Strictly speaking there
is no 
	such thing, Virtual LANs are being defined by IEEE 802.1 and not
only 
	for Ethernet. However accepting terminology license based on the

	de-facto reality that most if not all VLANs run over Ethernet,
there 
	still is a need to specify if the document refers to IEEE 802.1Q
VLANs 
	(one 12-bit tag) or IEEE 802.1ad which accommodate multiple tags
and 
	introduce the concepts of Customer VLAN and Service VLAN. Maybe
the 
	VLANs referred in this I-D are transparent to the type of VLANs
that are 
	being connected, but even so there should be text explaining
this.
	 
	  Elaboration for the term "Ethernet" and "VLAN" suggested by 
	  Ignacio Goyret and has been inserted into Introduction
section:
	 
	  " The term "Ethernet" in this draft is used with the intention
to
	   include all such protocols that are reasonably similar in
their
	   packet format to IEEE 802.3, including variants or extensions
which
	   may or may not necessarily be sanctioned by IEEE (including
such
	   things as jumbo frames, etc).  The term "VLAN" in this draft
is used
	   with the intention to include all virtual LAN tagging
protocols such
	   as IEEE 802.1Q, 802.1ad, etc."

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

---

From: "Maria A. Dos Santos \(mariados\)" <[email-masked]>
Date: Fri, 11 Aug 2006 10:29:38 -0700

Dan,

thanx for the review, I can add the references.

alice

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> Sent: Sunday, 6 August, 2006 4:26
> To: Maria A. Dos Santos (mariados); [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; Jari Arkko; Cullen Jennings 
> (fluffy); Mark Townsley (townsley)
> Subject: RE: Latest updates : draft-ietf-l2tpext-pwe3-ethernet-08.txt
> 
> I am happy with the text that addresses my DISCUSS, but I 
> suggest that IEEE 802.3, IEEE 802.1Q and IEEE802.1ad be 
> included as Normative References. 
>  
> Dan
>  
>  
>  
>  
> 
> 
> ________________________________
> 
> 	To: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; Jari Arkko; 
> Cullen Jennings (fluffy); Mark Townsley (townsley); 
> Romascanu, Dan (Dan)
> 	The following is the consolidated list of all the LC 
> comments and responses
> 	by different people.  I highlighted the responses and 
> what/how will be replaced.
> 	This has been reviewed by Ignacio Goyret once already 
> and I already 
> 	incorporated his last batch of editorial change 
> requests in the attached
> 	version 8 of the draft.
> 	 
> 	There is still one comment from Cullen Jennings which 
> is not resolved
> 	yet, but no response from Cullen yet.  Do others want 
> to advice on how
> 	to handle this comment?
> 	 
> 	regards,
> 	Alice
> 	 
> 	
> --------------------------------------------------------------
> -----------------------------------------------
> 	
> 	###
> 	   imported abbreviations in the logical (i.e., not 
> alpha) order.
> 	 
> 	   I propose to cite 802.1Q the first time and use 
> "VLAN" everywhere
> 	 - 2.3.2: to indicate the Ethernet interface -> plural 
> without "the"?
> 	 
> 	Fixed
> 	 
> 	 - 3.2: may -> MAY?
> 	 
> 	Fixed
> 	 
> 	 - (technical) 3.3: I am not convinced at all by the 
> very last part
> 	   (fragmentation/reassemble recommendation) because it 
> is a layer violation
> 	   and the goal (manage the issue at only one place as 
> explain in
> 	    Fragmentation and Reassembly procedures specified 
> in Section 5 of
> 	    [L2TPFRAG] or section 4.1.4 of [RFC3931] when the 
> Ethernet payload 
> 	    is IPv4.  Only one of these methods SHOULD be used 
> for a given 
> 	    Ethernet PW."
> 	 
> 	has been changed to:
> 	 
> 	   recommendations with respect to fragmentation and 
> reassembly in
> 	   reassembly mechanism within L2TP itself in the event 
> that no other
> 	   option is available.  Implementations MUST follow 
> these guidelines
> 	 - 4: For Ethernet VLAN PW, VLAN tag rewrite ...: can't 
> parse this statement
> 	 
> 
> 	  While architecturally [RFC3985] outside the scope of 
> the L2TPv3 PW 
> 	  itself, if VLAN tags are present, the NSP may rewrite 
> VLAN tags on 
> 	  The VLAN tags of an Ethernet VLAN PW may be rewritten 
> by NSP at
> 	  the egress LCCE, which is outside the scope of this 
> document (see
> 	  Section 3.1).
> 	 
> 	 - 4: there is no TOS octet or QoS field in the IP 
> header (look at RFC 2474?)
> 	 
> 
> 	Mark Townsley:
> 	 
> 	  > No doubt. We need to at a minimum change this to 
> "ToS bits"and strike 
> 	  > "IP QoS field" - the paragraph should perhaps 
> simply be rewritten to 
> 	  > refer to DSCP only.
> 	 
> 
> 	  >>>[BC] Indeed, there is no "for example" about it; 
> there only the DSCP.
> 	  >> 
> 	  >> 
> 	  >> RFC2474 specifically refers to that byte as "the 
> TOS octet" (eg, see 
> 	  >> How about eliminating the parenthesized "for 
> example, according to DSCP"?
> 	  >Well, it is called the TOS octet in IPv4 and the 
> Traffic Class octet in
> 	  >IPv6 - the only phrase that applies to both is DSCP. 
> So either you have 
> 	  >to put "TOS or Traffic Class octet" or refer to 
> 2474, I think.
> 	 
> 
> 	 - 4: 802.1Q CS and ... -> too many "and" (note that 
> here 802.1Q is the
> 	   right term)
> 	 
> 	Fixed
> 	 
> 	 5: should -> SHOULD ??
> 	 
> 	From Mark:
> 	 
> 	  I'm not entirely convinced that this is a SHOULD 
> given that it isn't 
> ##############################################################
> #############
> 	*Lars Eggert:*
> 	*Discuss:*
> 	 >    LCCEs SHOULD monitor for congestion (by using 
> explicit congestion
> 	 >    notification, or by measuring packet loss) in 
> order to ensure that
> 	 >    the service using the Ethernet or Ethernet VLAN 
> PW may be maintained.
> 	 >    When severe congestion is detected (for example 
> when enabling
> 	 >    Sequencing and detecting that the packet loss is 
> higher than a
> 	 >    threshold) the Ethernet or Ethernet VLAN PW 
> SHOULD be halted by
> 	 >    tearing down the L2TP session via a CDN message.  
> The PW may be
> 	 >    restarted by manual intervention, or by automatic 
> means after an
> 	 >    appropriate waiting time.  Note that the 
> thresholds and time periods
> 	 >    for shutdown and possible automatic recovery need 
> to be carefully
> 	 >    configured. This is necessary to avoid loss of 
> service due to
> 	 >    temporary congestion, and to prevent oscillation 
> between the
> 	  RFC3985 also says: "Where congestion is avoided by 
> shutting down a PW,
> 	  a suitable mechanism must be provided to prevent it 
> from immediately
> 	  returning to service and causing a series of 
> congestion pulses." I
> 	  against draft-ietf-pwe3-atm-encap. As far as I know, 
> PWE3 is working
> 	  on an approach for addressing this. This document, 
> however, belongs to
> 	  a different WG, so I'm not sure if any resolution 
> that PWE3 comes up
> 	  with would apply to this document as well. I'd hope 
> that it would -
> 	Confirmed by Stewart Bryant and Mark Townsley that the 
> PWE3 congestion work 
> ##############################################################
> #############
> 	*Cullen Jennings:*
> 	*Discuss:*
> 	   *[2006-07-05]* I may not understand the congestion 
> control technique but 
> 	   it looks like it says,  "in case of congestion, pull 
> the plug". I don't 
> 	   believe anyone will implement this congestion 
> control suggestions - and 
> 	   if they do, I don't believe the resulting systems 
> will be usable - they 
> 	   will be impossible to manage not to mention the 
> incredible DOS 
> 	   opportunities. No advice on the threshold is 
> provided. I think this 
> 	   needs to be updated to either be clear no congestion 
> control is provided.
> 	 
> 	From what I understand, the draft is inline with the 
> current state of congestion
> 	control for emulation technologies, and PWE3 WG is 
> currently conducting 
> 	further study on the topic.  Once we get the result of 
> that, this draft
> 	and all other pwe drafts (both l2tp and mpls) will 
> leverage from that
> 	mechanism.  So at this point, the goal of the 
> "Congestion Control" section 
> 	in this draft is only to emphasize the possibility of 
> congestion and provide
> 	some general best-effort recovery mechanisms.  Would it 
> be better if I emphasize
> 	the goal?
> 	 
> 	I am not sure what general default threshold is 
> appropriate given that the threshold will
> 	vary according to network size and average traffic load 
> of individual network.  That's why
> 	   The section titled "Applicability Statement" gives 
> me no idea where this 
> 	Would you mind elaborating what information are you 
> expecting here?
> 	 
> 	
> ##############################################################
> #############
> 	*Dan Romascanu:*
> 	*Discuss:*
> 	*[2006-07-03]* I made the following two comments during 
> the IESG LC. The 
> 	1. The I-D speaks about 'Ethernet' but does not provide 
> any reference.
> 	What version of the Ethernet standard is targeted here? 
> The latest 
> 	the IEEE 802.3 WG also has in works an extension of the 
> frame size as 
> 	IEEE 802.3as. One cannot talk about Ethernet PDU and 
> MTU without a 
> 	proper reference.
> 	 
> 	2. The I-D speaks about 'Ethernet VLAN'. Strictly 
> speaking there is no 
> 	such thing, Virtual LANs are being defined by IEEE 
> 802.1 and not only 
> 	de-facto reality that most if not all VLANs run over 
> Ethernet, there 
> 	still is a need to specify if the document refers to 
> IEEE 802.1Q VLANs 
> 	(one 12-bit tag) or IEEE 802.1ad which accommodate 
> multiple tags and 
> 	introduce the concepts of Customer VLAN and Service 
> VLAN. Maybe the 
> 	VLANs referred in this I-D are transparent to the type 
> of VLANs that are 
> 	being connected, but even so there should be text 
> explaining this.
> 	 
> 	  Ignacio Goyret and has been inserted into 
> Introduction section:
> 	 
> 	  " The term "Ethernet" in this draft is used with the 
> intention to
> 	   include all such protocols that are reasonably 
> similar in their
> 	   packet format to IEEE 802.3, including variants or 
> extensions which
> 	   may or may not necessarily be sanctioned by IEEE 
> (including such
> 	   things as jumbo frames, etc).  The term "VLAN" in 
> this draft is used
> 	   with the intention to include all virtual LAN 
> tagging protocols such

---

From: "Maria A. Dos Santos \(mariados\)" <[email-masked]>
Date: Mon, 21 Aug 2006 15:12:31 -0700

sure, I will post this version as "08.txt"

alice

> From: Ignacio Goyret [mailto:[email-masked]] 
> Sent: Monday, 21 August, 2006 15:09
> To: Maria A. Dos Santos (mariados)
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> (fluffy); Mark Townsley (townsley); Romascanu, Dan (Dan); 
> Carlos Pignataro (cpignata)
> Subject: Re: Latest updates : draft-ietf-l2tpext-pwe3-ethernet-08.txt
> 
> Mark, can you ping Cullen please?
> 
> In the meantime, I'd suggest that you publish a new draft as 
> it's easier to track that way.
> 
> -Ignacio
> 
> 
> At 14:15 8/21/2006 -0700, Maria A. Dos Santos \(mariados\) wrote: 
> >
> > As Dan requested, I included the normative references to the IEEE 
> > standards in this version.
> >  
> > I still haven't heard from Cullen Jennings on the discuss 
> he raised.  
> > Please advice on how to proceed with this.
> >  
> > regards,
> > Alice
> >  
> >
> 
>

---

From: Ignacio Goyret <[email-masked]>
Date: Mon, 21 Aug 2006 15:08:50 -0700

In the meantime, I'd suggest that you publish a new draft as it's easier
to track that way.

-Ignacio

At 14:15 8/21/2006 -0700, Maria A. Dos Santos \(mariados\) wrote: 
>
> As Dan requested, I included the normative references to the IEEE standards
> in this version.
>  
> I still haven't heard from Cullen Jennings on the discuss he raised.  Please 
> advice on how to proceed with this.
>  
> regards,
> Alice
>  
>

---

From: "Maria A. Dos Santos \(mariados\)" <[email-masked]>
Date: Tue, 22 Aug 2006 11:24:38 -0700

Cullen, thx for the reply, will respond to you shortly.

alice

> From: Cullen Jennings (fluffy) 
> Sent: Monday, 21 August, 2006 17:17
> [email-masked]; Jari Arkko; Mark Townsley 
> (townsley); Romascanu, Dan (Dan)
> My apologies - I did not realize there was text for me in 
> this email till I got the ping today :-) More inline ...
> 
> On Aug 4, 2006, at 12:03 PM, Maria A. Dos Santos ((mariados)) wrote:
> 
> 
> 	
> 	
> I'd have no problem with something along the lines of: 
> 
> This specification offers no congestion control and is not 
> TCP friendly <add ref to where TCP Friendly is define>. 
> Future works, such as <insert non normative reference that 
> will not block your document>, may extend this to provide 
> congestion control.
> 
> 
> 	
> 	 
> Hmm - I know something about networks and I have no idea how 
> I would set up the parameters such that they would work and 
> not mess up other protocols on the same network. I understand 
> that how you might want the parameters on a satellite link, 
> vs a corporate switched LAN, to be somewhat different. I view 
> the problem with selecting numbers here is that no matter 
> what you pick, it is clear many people will disagree with it 
> and there will be cases where it does not work. That is 
> typically a sign that algorithm might be less than ideal 
> regardless of the parameters. However, if we are agreed that 
> for practical deployments and implementation, we expect that 
> PWE will not have automated congestion control, then I have 
> no real problem with the text you have here and we can just 
> ignore trying to figure out if this provides enough advice 
> that anyone will be able to get something that works. 
> 
> 
> 	
> 	 
> I might have this wrong but talking to people I get the idea 
> that the expectation is that this protocol will be used 
> across the public internet  as well as private networks and 
> will be used for many things including forming virtual 
> network connection between remote offices for enterprises. 
> 
> 
> 
> 
>

---

From: "Maria A. Dos Santos \(mariados\)" <[email-masked]>
Date: Wed, 23 Aug 2006 00:26:36 -0700

ok, will do.  thx.
alice

> From: Brian E Carpenter [mailto:[email-masked]] 
> Sent: Wednesday, 23 August, 2006 0:18
> Subject: Re: [Gen-art] Latest updates : 
> I've cleared my DISCUSS now that -08 is posted. You can drop 
> gen-art from this thread, I think.
> 
> Thanks
> 
>      Brian
> 
> 
> Maria A. Dos Santos (mariados) wrote:

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Wed, 23 Aug 2006 13:09:08 +0300

I also cleared my DISCUSS.

Dan

> Sent: Wednesday, August 23, 2006 10:18 AM

---

From: "Maria A. Dos Santos \(mariados\)" <[email-masked]>
Date: Wed, 23 Aug 2006 09:30:35 -0700

ok, thankyou 

alice =) 

> Sent: Wednesday, 23 August, 2006 3:09
> To: Brian E Carpenter; Maria A. Dos Santos (mariados)
> (fluffy); Mark Townsley (townsley); Carlos Pignataro (cpignata)
> Subject: RE: [Gen-art] Latest updates : 
> (fluffy); Mark 
> > Townsley (townsley); Romascanu, Dan (Dan); Carlos Pignataro 
> (cpignata)
> > I've cleared my DISCUSS now that -08 is posted. You can 
> drop gen-art 
> > from this thread, I think.
> > 
> > Thanks
> > 
> >      Brian
> > 
> >