Subject: Re: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document

From: "Zafar Ali (zali)" <[email-masked]>
Date: Mon, 3 Jun 2013 14:40:21 +0000

Hi Loa and all- 

Support,

Thanks

Regards Š Zafar 

-----Original Message-----
From: Loa Andersson <[email-masked]>
Date: Thursday, May 30, 2013 12:35 PM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>,
"[email-masked]"
<[email-masked]>
Subject: [mpls] Poll to see if we have consensus to make
draft-lim-mpls-proxy-lsp-ping an MPLS working group document

>Working Group,
>
>This is to start a two week poll on adopting
>draft-lim-mpls-proxy-lsp-ping-02 as an MPLS working group document.
>
>Please send your comments (support/not support) to the mpls working
>group mailing list (mpls at ietf.org). Please give a technical
>motivation for your support/not support, especially if you think that
>the document should not be adopted as a working group document.
>
>This poll ends June 14, 2013.
>
>There are two IPR claims against this document:
>
>https://datatracker.ietf.org/ipr/778/
>https://datatracker.ietf.org/ipr/2087/
>
>
>The authors has stated on the working group mailing list
>that they are not aware of any other IPR claims against this draft.
>However if you are on the the mpls working group mailing list and
>aware of IPR that relates to this draft, the time to disclose
>this is now.
>
>/Loa
>(mpls wg co-chair)
>-- 
>
>
>Loa Andersson                        email: [email-masked]
>Senior MPLS Expert                          [email-masked]
>Huawei Technologies (consultant)     phone: +46 739 81 21 64
>_______________________________________________
>mpls mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mpls

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Mon, 3 Jun 2013 14:47:27 +0000

Support.
Luyuan

---

From: "Siva Sivabalan (msiva)" <[email-masked]>
Date: Mon, 3 Jun 2013 14:52:23 +0000

Yes, support.

Thanks,
Siva

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Thursday, May 30, 2013 12:35 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document

Working Group,

Please send your comments (support/not support) to the mpls working group mailing list (mpls at ietf.org). Please give a technical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document.

The authors has stated on the working group mailing list that they are not aware of any other IPR claims against this draft.
However if you are on the the mpls working group mailing list and aware of IPR that relates to this draft, the time to disclose this is now.

/Loa
(mpls wg co-chair)
--

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Mon, 3 Jun 2013 15:01:14 +0000

Support.

Regards,
Nobo

> Subject: [mpls] Poll to see if we have consensus to make draft-lim-mpls-
> proxy-lsp-ping an MPLS working group document
> 
> Working Group,
> 
> group mailing list (mpls at ietf.org). Please give a technical motivation for
> your support/not support, especially if you think that the document should
> not be adopted as a working group document.
> 
> The authors has stated on the working group mailing list that they are not
> aware of any other IPR claims against this draft.
> However if you are on the the mpls working group mailing list and aware of
> IPR that relates to this draft, the time to disclose this is now.
> 
> /Loa
> (mpls wg co-chair)
> --
> 
>

---

From: "Michael Wildt (mwildt)" <[email-masked]>
Date: Mon, 3 Jun 2013 15:16:29 +0000

Support.

Thanks
Michael

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Thursday, May 30, 2013 12:35 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document

Working Group,

/Loa
(mpls wg co-chair)
--

---

From: "Sami Boutros (sboutros)" <[email-masked]>
Date: Mon, 3 Jun 2013 16:01:48 +0000

Support.

Thanks,

Sami

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 3 Jun 2013 16:45:12 +0000

Support.

I support adoption of this document as it solves scalable OAM in multipoint scenarios, real problem and sound technical solution.

Thanks,

-- Carlos.

---

From: Richard Li <[email-masked]>
Date: Mon, 3 Jun 2013 17:39:37 +0000

Support.

/Richard

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Thursday, May 30, 2013 9:35 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document

Working Group,

/Loa
(mpls wg co-chair)
--

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 3 Jun 2013 19:25:47 +0000

Support.

Cheers,
Rajiv

Sent from my Phone

---

From: Huaimo Chen <[email-masked]>
Date: Mon, 3 Jun 2013 19:58:58 +0000

Support.

Best Regards,
Huaimo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Thursday, May 30, 2013 12:35 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document

Working Group,

/Loa
(mpls wg co-chair)
--

---

From: "Nagendra Kumar (naikumar)" <[email-masked]>
Date: Tue, 4 Jun 2013 00:49:11 +0000

Support

Regards,
Nagendra

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Thursday, May 30, 2013 10:05 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document

Working Group,

/Loa
(mpls wg co-chair)
--

---

From: Mach Chen <[email-masked]>
Date: Tue, 4 Jun 2013 01:04:49 +0000

Yes/support

Best regards,
Mach

> Sent: Friday, May 31, 2013 12:35 AM
> To: [email-masked]

---

From: Ping Pan <[email-masked]>
Date: Tue, 4 Jun 2013 05:34:19 -0700

+1
On Jun 3, 2013 6:42 PM, "Mach Chen" <[email-masked]> wrote:

> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Loa
> > Andersson
> > Cc: [email-masked];
> [email-masked]

---

From: Lucy yong <[email-masked]>
Date: Tue, 4 Jun 2013 15:40:08 +0000

Support!

Cheers,
Lucy

> Loa Andersson
> Sent: Thursday, May 30, 2013 11:35 AM
> To: [email-masked]
> Subject: [mpls] Poll to see if we have consensus to make draft-lim-
> mpls-proxy-lsp-ping an MPLS working group document
> 
> Working Group,
>

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 5 Jun 2013 09:34:27 +0530

Support. 

****************************************************************************
***
Dhruv Dhody, System Architect, Huawei Technologies, Bangalore, India, Ph.
+91-9845062422
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

Loa

---

From: Eric Gray <[email-masked]>
Date: Wed, 5 Jun 2013 19:01:33 +0000

Don't support at the current time.

The draft does not appear to deal reasonably with the case where a desired remote 
"Proxy LSP Ping" LSR does not support this capability.  I searched and the phrase
"backward compatibility" is not in the full-text version of the draft.

I also have some questions about the utility of this capability, given that this might - 
for instance - be used by an edge router to task other routers with "pinging" toward 
another edge router.  Presumably, this could include routers which are typically not
optimized to handle processing of traffic such as Ping responses.

This could be made very much worse if - within the context of the service provider 
network - a large number of edge LSRs were compromised and became agents in a 
DDoS attack on the service provider core network.
--
Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Thursday, May 30, 2013 12:35 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document

Working Group,

/Loa
(mpls wg co-chair)
--

---

From: Eric Gray <[email-masked]>
Date: Wed, 5 Jun 2013 21:26:27 +0000

In addition to the previously noted issues, from discussion, it looks like the values "assigned"
in the IANA considerations section are at least questionable at this point.

At present, there is only one obvious clash in these assignments (the draft "assigns" the value
"5" in the "Downstream [Mapping Address Type] Registry" and this value has already been 
assigned via RFC 6426).  However, the MPLS WG now has in place an early assignment process 
and it may be the case that other assignments have been made via this process and a clash will 
occur when these are permanently assigned later.

As a NIT - compounding the issues in this case - two of the affected Registries are incorrectly
named in the IANA section.

These values should be replaced with "variables" (e.g. - TBA-1, TBA-2, TBA-3, etc.) before the
draft is adopted as a WG draft.  Once adopted, the authors of this draft may then apply for 
early assignments via the existing process.

--
Eric

-----Original Message-----
From: Eric Gray 
Sent: Wednesday, June 05, 2013 3:02 PM
To: 'Loa Andersson'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document

The draft does not appear to deal reasonably with the case where a desired remote "Proxy LSP Ping" LSR does not support this capability.  I searched and the phrase "backward compatibility" is not in the full-text version of the draft.

I also have some questions about the utility of this capability, given that this might - for instance - be used by an edge router to task other routers with "pinging" toward another edge router.  Presumably, this could include routers which are typically not optimized to handle processing of traffic such as Ping responses.

This could be made very much worse if - within the context of the service provider network - a large number of edge LSRs were compromised and became agents in a DDoS attack on the service provider core network.
--
Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Thursday, May 30, 2013 12:35 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document

Working Group,

/Loa
(mpls wg co-chair)
--

---

From: Loa Andersson <[email-masked]>
Date: Thu, 06 Jun 2013 11:22:27 +0200

Eric,

You point at an issue that we need to resolve.

 From a working group point of view there is no "early allocation" made
for draft-lim-mpls-proxy-lsp-ping; as a matter of fact there can't be
any early allocation made, since these can be made only to working group
documents. RFC 4020 says "The processes described below assume that the
document in question is the product of an IETF Working Group."

There is a practice among many authors to "propose" values in the IANA
section. For new registries this is at least semi-encouraged.

For existing registries this practice is most of the time not harmful,
but could create problems if the proposed values are actually used in
implementations. It is RECOMMENDED that our documents use the tbd-1
style variables.

The problem here is the definition of "our documents", strictly
draft-lim-mpls-proxy-lsp-ping does really meet the criteria to be
one of "our documents" until it actually is accepted as a working
group document - when the working group take over the revision
control.

The working group can't tell the authors what to do with the document,
until it becomes a working group document! My conclusion is that the
issues on the IANA allocation you point to is a reason to making it a
working group document.

There are potential "clashes", both draft-lim-mpls-proxy-lsp-ping and
draft-ietf-mpls-return-path-specified-lsp-ping are looking to assign
new TLV Type values, it might be that the value proposed by
draft-lim-mpls-proxy-lsp-ping (Type 22) is already assigned when we
request publication of theis draft.

Note: draft-lim-mpls-proxy-lsp-ping is currently in wg poll and should
       for the time being not be updated.

/Loa

--

---

From: Eric Gray <[email-masked]>
Date: Thu, 6 Jun 2013 14:17:54 +0000

Loa,

	Mostly good points.  However, it is frequently the case that the WG chairs require 
certain changes to be made - other than the obvious "name change" for the draft - based on
comments made during the polling for adoption.

	This is by no means unusual.

	This is what I am suggesting needs to be done in this case - i.e. - if the draft is adopted
by the WG, it should not be published as a WG draft without fixing the IANA section.

	As to the point you make about the faults in the IANA section being a good reason to
adopt the draft as a working group draft - well - sorry but that is ridiculous (as I am sure you
will realize if you think about it).  If that were true, the easiest way to get any draft adopted
by the WG would be to abuse the IANA Considerations section.

	We would clearly be risking setting a dangerous precedent by even suggesting this.

	What should instead be the case is that any private draft that expects to use an IANA
registry that is "owned" by an IETF working group MUST use the "tbd-#" style variables or it
can be explicitly removed from the ID repository based on a request from the chair(s) of that
working group.

--
Eric

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]] 
Sent: Thursday, June 06, 2013 5:22 AM
To: Eric Gray
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document
Importance: High

Eric,

 From a working group point of view there is no "early allocation" made for draft-lim-mpls-proxy-lsp-ping; as a matter of fact there can't be any early allocation made, since these can be made only to working group documents. RFC 4020 says "The processes described below assume that the document in question is the product of an IETF Working Group."

There is a practice among many authors to "propose" values in the IANA section. For new registries this is at least semi-encouraged.

For existing registries this practice is most of the time not harmful, but could create problems if the proposed values are actually used in implementations. It is RECOMMENDED that our documents use the tbd-1 style variables.

The problem here is the definition of "our documents", strictly draft-lim-mpls-proxy-lsp-ping does really meet the criteria to be one of "our documents" until it actually is accepted as a working group document - when the working group take over the revision control.

The working group can't tell the authors what to do with the document, until it becomes a working group document! My conclusion is that the issues on the IANA allocation you point to is a reason to making it a working group document.

There are potential "clashes", both draft-lim-mpls-proxy-lsp-ping and draft-ietf-mpls-return-path-specified-lsp-ping are looking to assign new TLV Type values, it might be that the value proposed by draft-lim-mpls-proxy-lsp-ping (Type 22) is already assigned when we request publication of theis draft.

/Loa

On 2013-06-05 23:26, Eric Gray wrote:
> At present, there is only one obvious clash in these assignments (the 
> draft "assigns" the value "5" in the "Downstream [Mapping Address 
> Type] Registry" and this value has already been assigned via RFC 
> 6426).  However, the MPLS WG now has in place an early assignment 
> process and it may be the case that other assignments have been made via this process and a clash will occur when these are permanently assigned later.
>
> As a NIT - compounding the issues in this case - two of the affected 
> Registries are incorrectly named in the IANA section.
>
> These values should be replaced with "variables" (e.g. - TBA-1, TBA-2, 
> TBA-3, etc.) before the draft is adopted as a WG draft.  Once adopted, 
> the authors of this draft may then apply for early assignments via the existing process.
>
> --
> Eric
>
> Subject: RE: [mpls] Poll to see if we have consensus to make 

--

---

From: t.petch <[email-masked]>
Date: Fri, 7 Jun 2013 14:49:17 +0100

----- Original Message -----
From: "Eric Gray" <[email-masked]>
To: "Loa Andersson" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Thursday, June 06, 2013 3:17 PM

Eric

I think otherwise.  My experience in the IETF is that when an I-D is
adopted by a WG, then the only change is to the title.  Often the
instruction from the WG Chair explicitly spells this out.

Of course, changes can be made beforehand, to smooth the adoption, and
after, under the control of the WG, but at adoption, I think best not;
what might be uncontentious to one party might be a reason for changing
their mind to another, so only changing the name obviates that.

I agree that the IANA Considerations need work.  It would be better IMO
if the authors took out the 'hard' values beforehand.  If I had to
express an opinion, then it would be not to adopt until all those values
had been removed (which is not exactly a technical reason).

Tom Petch

> Cc: [email-masked]; [email-masked];
> Subject: Re: [mpls] Poll to see if we have consensus to make
>  From a working group point of view there is no "early allocation"
made for draft-lim-mpls-proxy-lsp-ping; as a matter of fact there can't
be any early allocation made, since these can be made only to working
group documents. RFC 4020 says "The processes described below assume
that the document in question is the product of an IETF Working Group."
> The problem here is the definition of "our documents", strictly
draft-lim-mpls-proxy-lsp-ping does really meet the criteria to be one of
"our documents" until it actually is accepted as a working group
document - when the working group take over the revision control.
> There are potential "clashes", both draft-lim-mpls-proxy-lsp-ping and
draft-ietf-mpls-return-path-specified-lsp-ping are looking to assign new
TLV Type values, it might be that the value proposed by
draft-lim-mpls-proxy-lsp-ping (Type 22) is already assigned when we
request publication of theis draft.
> > process and it may be the case that other assignments have been made
via this process and a clash will occur when these are permanently
assigned later.
> > The draft does not appear to deal reasonably with the case where a
desired remote "Proxy LSP Ping" LSR does not support this capability.  I
searched and the phrase "backward compatibility" is not in the full-text
version of the draft.
> >
> > I also have some questions about the utility of this capability,
given that this might - for instance - be used by an edge router to task
other routers with "pinging" toward another edge router.  Presumably,
this could include routers which are typically not optimized to handle
processing of traffic such as Ping responses.
> >
> > This could be made very much worse if - within the context of the
service provider network - a large number of edge LSRs were compromised
and became agents in a DDoS attack on the service provider core network.
> > The authors has stated on the working group mailing list that they
are not aware of any other IPR claims against this draft.
> > However if you are on the the mpls working group mailing list and
aware of IPR that relates to this draft, the time to disclose this is
now.

---

From: Loa Andersson <[email-masked]>
Date: Fri, 07 Jun 2013 16:00:08 +0200

Fokks,

<chair hat off>

I'd prefer that the hard values before going to poll to make
it a working group document;

<chair hat on>

but as a working group chair I would not require that any authors
make any changes to any non-working group documents.

There are things that needs to be fixed before starting the poll;
a perfect IANA section is not one of them. Updating the IANA sections
as part of what we do to working group documents; I guess there are
numerous author groups that can verify that that happens prior to
the request publication.

I see no reason to treat drfat-lim- differently.

/Loa

--

---

From: Eric Gray <[email-masked]>
Date: Fri, 7 Jun 2013 14:18:11 +0000

Loa,

                This would be acceptable to me, provided that the authors and the WG chairs make it a priority

to fix the IANA considerations section immediately after adoption, AND provided that the Chairs instruct

the draft authors to remove the instance where the draft is known to use a value already assigned in a

published RFC prior to reposting it as a WG draft.

                There is a big difference between telling a draft author to make changes in his or her draft while

it remains a private draft and telling them conditions under which it may be published as a working group

draft.

                As a working group, we certainly can say "we will adopt your private draft as a working group

draft, provided you make these specified  changes."  As a working group, we have a responsibility not

to ignore blatant errors in draft that will be a working group draft - no matter when we discover them.

                And, as I have already said, there are clearly cases where draft authors may inadvertently

include inappropriate abuse of IETF resources where it MUST be the case that working group chairs

and/or the IESG can direct either correction or removal of the draft - whatever its status at the time.

                By the way, just to avoid any confusion, I did not ask for a "perfect IANA section" - I asked only

that we not adopt an Internet Draft where the IANA section is clearly and specifically wrong.

--

Eric

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]]
Sent: Friday, June 07, 2013 10:00 AM
To: t.petch
Cc: Eric Gray; mpls; [email-masked]; [email-masked]
Subject: Re: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document

Fokks,

<chair hat off>

I'd prefer that the hard values before going to poll to make it a working group document;

<chair hat on>

but as a working group chair I would not require that any authors make any changes to any non-working group documents.

There are things that needs to be fixed before starting the poll; a perfect IANA section is not one of them. Updating the IANA sections as part of what we do to working group documents; I guess there are numerous author groups that can verify that that happens prior to the request publication.

/Loa

> From: "Eric Gray" <[email-masked]<mailto:[email-masked]>>

> To: "Loa Andersson" <[email-masked]<mailto:[email-masked]>>

> Cc: <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>;

> <[email-masked]<mailto:[email-masked]>>

>> Mostly good points.  However, it is frequently the case that the WG

> chairs require

>> certain changes to be made - other than the obvious "name change" for

> the draft - based on

> what might be uncontentious to one party might be a reason for

> changing their mind to another, so only changing the name obviates that.

> I agree that the IANA Considerations need work.  It would be better

> IMO if the authors took out the 'hard' values beforehand.  If I had to

> express an opinion, then it would be not to adopt until all those

> values had been removed (which is not exactly a technical reason).

>> This is what I am suggesting needs to be done in this case - i.e. -

>> if

> the draft is adopted

>> by the WG, it should not be published as a WG draft without fixing

>> the

> IANA section.

>> As to the point you make about the faults in the IANA section being a

> good reason to

>> adopt the draft as a working group draft - well - sorry but that is

> ridiculous (as I am sure you

>> will realize if you think about it).  If that were true, the easiest

> way to get any draft adopted

>> We would clearly be risking setting a dangerous precedent by even

> suggesting this.

>> What should instead be the case is that any private draft that

>> expects

> to use an IANA

>> registry that is "owned" by an IETF working group MUST use the "tbd-#"

> style variables or it

>> can be explicitly removed from the ID repository based on a request

> from the chair(s) of that

>> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;

> [email-masked]<mailto:[email-masked]>

> made for draft-lim-mpls-proxy-lsp-ping; as a matter of fact there

> can't be any early allocation made, since these can be made only to

> working group documents. RFC 4020 says "The processes described below

> assume that the document in question is the product of an IETF Working Group."

>> There is a practice among many authors to "propose" values in the

>> IANA

>> For existing registries this practice is most of the time not

>> harmful,

> draft-lim-mpls-proxy-lsp-ping does really meet the criteria to be one

> of "our documents" until it actually is accepted as a working group

>> The working group can't tell the authors what to do with the

>> document,

>>> In addition to the previously noted issues, from discussion, it

> looks like the values "assigned"

>>> in the IANA considerations section are at least questionable at this

> point.

>>> At present, there is only one obvious clash in these assignments

> (the

>>> These values should be replaced with "variables" (e.g. - TBA-1,

> TBA-2,

>>> TBA-3, etc.) before the draft is adopted as a WG draft.  Once

> adopted,

>>> the authors of this draft may then apply for early assignments via

> the existing process.

>>> To: 'Loa Andersson'; [email-masked]<mailto:[email-masked]>

>>> Cc: [email-masked]<mailto:[email-masked]>;

>>> [email-masked]<mailto:[email-masked]>

> desired remote "Proxy LSP Ping" LSR does not support this capability.

> I searched and the phrase "backward compatibility" is not in the

> full-text version of the draft.

> given that this might - for instance - be used by an edge router to

> task other routers with "pinging" toward another edge router.

> Presumably, this could include routers which are typically not

> service provider network - a large number of edge LSRs were

> compromised and became agents in a DDoS attack on the service provider core network.

>>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf

>>> Of Loa Andersson

>>> To: [email-masked]<mailto:[email-masked]>

>>> Cc: [email-masked]<mailto:[email-masked]>;

>>> [email-masked]<mailto:[email-masked]>

>> Loa Andersson                        email: [email-masked]<mailto:[email-masked]>

>> Senior MPLS Expert                          [email-masked]<mailto:[email-masked]>

>> [email-masked]<mailto:[email-masked]>

--

Loa Andersson                        email: [email-masked]<mailto:[email-masked]>

Senior MPLS Expert                          [email-masked]<mailto:[email-masked]>

---

From: Loa Andersson <[email-masked]>
Date: Mon, 17 Jun 2013 16:34:54 +0200

Working Group,

This poll has been closed. The working group chairs have noted that
there is consensus to adopt the document as a working group document.
However based on the discussion on the MPLS list we also think there
are some minor changes that are needed before accepting the document.

We will instruct the authors to update and the document. This will be
done in a separate mail-thread between the authors and the wg-chairs
and will be based on the discussion on the MPLS list during the call
for adoption.

Assuming that the document is updated appropriately, the wg-chairs
may take the decision to accept the document without a further poll.

/Loa
for the mpls wg co-chairs

--