Subject: [Pce] WGLC for draft-ietf-pce-association-policy

From: Dhruv Dhody <[email-masked]>
Date: Fri, 4 Sep 2020 10:43:09 +0530

Hi WG,

This email starts a working group last call for
draft-ietf-pce-association-policy [1].  Please indicate your support
or concern for this draft. If you are opposed to the progression of
the draft to RFC, please articulate your concern. If you support it,
please indicate that you have read the latest version and it is ready
for publication in your opinion. As always, review comments and nits
are most welcome.

The WG LC will end on 21st September 2020.

Thanks,
Dhruv & Julien
[1] https://datatracker.ietf.org/doc/draft-ietf-pce-association-policy/

---

From: Huaimo Chen <[email-masked]>
Date: Fri, 11 Sep 2020 20:23:12 +0000

Hi Authors,

    It is an interesting topic.
    I have the following comments after reading through the draft.

    1) Section 3 defines IFIT capability TLV. Some details about the procedures
related to it seems missing. For example, after a PCEP session between A
and B is established, A sends B a PCEP message with IFIT Attributes TLVs
only if B supports IFIT capability (i.e., A has received from B the IFIT
capability TLV in the OPEN message). What happens if A receives a PCEP message
with IFIT Attributes TLVs from B but B does not support IFIT capability?

    2) Section 4 defines IFIT Attributes TLV and its sub-TLVs.
It would be better to have some general procedures for handling the TLV.

    3) For Section 5 "Example of operation", its title seems not fit well
with its contents, which illustrates some procedures for handling PCEP
messages with IFIT Attributes TLVs. There should be a section about
Operations, which focuses on configurations of IFIT feature.

    4) Some nits:
a) page 3, in the 5th paragraph, "is focused" should be "focuses".
b) page 4, in the last paragraph, "TLVs" should be "TLV".
c) page 5, in the first paragraph, "and and" should be "and".

Best Regards,
Huaimo

---

From: Jeff Tantsura <[email-masked]>
Date: Sat, 12 Sep 2020 11:25:58 +0200

Support as co-author

Cheers,
Jeff

> On Sep 4, 2020, at 07:13, Dhruv Dhody <[email-masked]> wrote:
> 
> Hi WG,
>

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Mon, 14 Sep 2020 02:15:45 +0000

Support as a co-author. 

This document provides a useful mechanism for associating policies to LSPs. 

Comments: more details should be added in the abstract.

Respect,
Cheng

-----Original Message-----
From: Dhruv Dhody [mailto:[email-masked]] 
Sent: Friday, September 4, 2020 1:13 PM
To: [email-masked]
Cc: [email-masked]; pce-chairs <[email-masked]>
Subject: WGLC for draft-ietf-pce-association-policy

Hi WG,

This email starts a working group last call for draft-ietf-pce-association-policy [1].  Please indicate your support or concern for this draft. If you are opposed to the progression of the draft to RFC, please articulate your concern. If you support it, please indicate that you have read the latest version and it is ready for publication in your opinion. As always, review comments and nits are most welcome.

Thanks,
Dhruv & Julien

---

From: Giuseppe Fioccola <[email-masked]>
Date: Tue, 15 Sep 2020 11:54:56 +0000

Hi Huaimo,
Thanks a lot for your review of the document.
Please find my answers inline tagged as [GF].
We will work on a new version soon.

Regards,

Giuseppe

From: Huaimo Chen [mailto:[email-masked]]
Sent: Friday, September 11, 2020 10:23 PM
To: [email-masked]
Cc: [email-masked]
Subject: draft-chen-pce-pcep-ifit-00

Hi Authors,

[GF]: Section 3 will be extended and we will include the 5 different capabilities for IOAM and Alternate Marking. In this way each capability can be advertised separately and, in addition, a node can selectively signal the particular capability that is not supported instead of the general IFIT flag.

[GF]: Good point. I think the procedures of handling the TLV could be detailed in a following section that we can propose in the next revision.

[GF]: Agree, we can change the title of this section to "Procedure Considerations" and describe both PCEP message exchange and, as you suggest, the configurations of the IFIT features that enable data plane telemetry. For more details on the telemetry we can add the reference to the relevant documents for data plane.

    4) Some nits:

[GF]: Thanks, will do.

Best Regards,
Huaimo

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 17 Sep 2020 15:12:05 +0530

Hi WG,

A reminder to the WG to be more vocal. I am copying this slide from
the chair's WG status slide
[https://www.ietf.org/proceedings/108/slides/slides-108-pce-1-introduction-01]

> Please be Vocal
>
> o During WG Adoption and WG LC calls, the response is less.
>
> o Please be vocal on the list to help us gauge the consensus better.
>
> o The working group mailing lists are looked at by the IESG, IAB, and others (internal and external to IETF) to determine interest/participation level in our standards process.
>
> o Please review ideas from your peers, these are community outputs of the working group as a whole.
>

The WG LC for the draft in question ends on Monday 21st Sept. Please
respond with your explicit support (or not) for its publication.

Thanks!
Dhruv & Julien

---

From: "Mike Koldychev (mkoldych)" <[email-masked]>
Date: Thu, 17 Sep 2020 17:30:19 +0000

I support this document.

It provides a useful mechanism to apply policies either on the PCC or on the PCE.

Comment: it should be clarified whether PCUpd message can be used instead of the PCInit message when updating the PAG that is "enforced by the PCC". I believe PCUpd can be used, but the draft should make that explicit, for example in Figure 1.

Thanks,
Mike.

-----Original Message-----
From: Pce <[email-masked]> On Behalf Of Dhruv Dhody
Sent: Friday, September 4, 2020 1:13 AM
To: [email-masked]
Cc: [email-masked]; pce-chairs <[email-masked]>
Subject: [Pce] WGLC for draft-ietf-pce-association-policy

Hi WG,

Thanks,
Dhruv & Julien

_______________________________________________
Pce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pce

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 18 Sep 2020 09:12:56 +0800

Hi, Authors:

I Just have a quick view of this draft, and has some points wanted to be
clarified:
1. This draft defines one new association type (policy association type)
that follows the procedures described in RFC8697 and attached TLV? Is it
right?
2. According to the text described in
https://tools.ietf.org/html/rfc8697#section-3.2, to define one new
association type, the related draft should clarify its relationship between
the SVEC object, if any. 
Should this draft to add such part? 
3. For the definition of "Policy-Parameters-TLV", the "Policy Parameters" is
opaque value to the PCEP peers.  The draft describes the PCEP peers should
know how to the encoding format of such policy in advance. But from my POV,
the encoding format is the main content needs to be standardized. If such
contents can't be standardized, what benefit can we get from this
standardization work? What's the reason not to standardize this?

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dhruv
Dhody
Sent: Thursday, September 17, 2020 5:42 PM
To: [email-masked]
Cc: [email-masked]; pce-chairs
<[email-masked]>
Subject: Re: [Pce] WGLC for draft-ietf-pce-association-policy

Hi WG,

A reminder to the WG to be more vocal. I am copying this slide from the
chair's WG status slide
[https://www.ietf.org/proceedings/108/slides/slides-108-pce-1-introduction-0
1]

> o The working group mailing lists are looked at by the IESG, IAB, and
others (internal and external to IETF) to determine interest/participation
level in our standards process.
> o Please review ideas from your peers, these are community outputs of the
working group as a whole.

The WG LC for the draft in question ends on Monday 21st Sept. Please respond
with your explicit support (or not) for its publication.

Thanks!
Dhruv & Julien

On Fri, Sep 4, 2020 at 10:43 AM Dhruv Dhody <[email-masked]> wrote:
> [1] 
> https://datatracker.ietf.org/doc/draft-ietf-pce-association-policy/

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 18 Sep 2020 10:09:35 +0530

Hi Aijun,

Thank you for your comments.

I wanted to focus on the 3rd point. I remember this being discussed
perhaps in the previous incarnation of the draft. The main motivation
in PCEP is to provide a "standard" container and mechanism to
associate (and encode the policy) and leave the actual policy
standardization out of the scope of PCEP.

Another way to look at this would be, when a policy is well-known and
needs to be standardized (some may consider diversity or SR-Policy as
those policies), we define a new standard association-type for it with
a standard TLV. This I-D is used when we do not have a standard policy
defined in PCEP but would like to use the protocol as an opaque
container to associate policies to the path. What does that policy
mean and how to encode/decode the policy parameters are expected to be
done out-of-band via other mechanisms which are better suited for
policy definitions and configurations at the PCEP speakers.  Hope this
helps!

Thanks!
Dhruv (hat-less!)

---

From: Rakesh Gandhi <[email-masked]>
Date: Fri, 18 Sep 2020 14:26:08 -0400

Hi WG, Chairs,

Yes, support, I believe it is ready for publication.

Thanks,
Rakesh

 -----Original Message-----

> draft-ietf-pce-association-policy [1].  Please indicate your support or
> concern for this draft. If you are opposed to the progression of the draft
> to RFC, please articulate your concern. If you support it, please indicate
> that you have read the latest version and it is ready for publication in
> your opinion. As always, review comments and nits are most welcome.
>

---

From: Lizhenbin <[email-masked]>
Date: Sat, 19 Sep 2020 01:48:07 +0000

I support the last call.

Best Regards,

Zhenbin (Robin)

--------------------------------------------------
李振斌 Li Zhenbin
Mobile: +86-13651017745<tel:+86-13651017745>/+968-91797068
Email: [email-masked]<mailto:[email-masked]>

发件人：Dhruv Dhody <[email-masked]>
收件人：pce <[email-masked]>
抄 送：draft-ietf-pce-association-policy <[email-masked]>;pce-chairs <[email-masked]>
时 间：2020-09-04 13:14:26
主 题：[Pce] WGLC for draft-ietf-pce-association-policy

Hi WG,

Thanks,
Dhruv & Julien

---

From: Tianran Zhou <[email-masked]>
Date: Sat, 19 Sep 2020 01:54:15 +0000

Hi WG and the Chairs,

I think it's ready for publication.

Tianran

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: Friday, September 4, 2020 1:13 PM
To: [email-masked]
Cc: [email-masked]; pce-chairs <[email-masked]>
Subject: [Pce] WGLC for draft-ietf-pce-association-policy

Hi WG,

Thanks,
Dhruv & Julien

---

From: Mahend Negi <[email-masked]>
Date: Sat, 19 Sep 2020 18:58:46 +0530

Support as co-author.

Regards,
Mahendra

---

From: Mach Chen <[email-masked]>
Date: Sun, 20 Sep 2020 08:14:34 +0000

Hi,

I have read the latest version of the document, I think it's ready for publication.

Best regards,
Mach

> concern for this draft. If you are opposed to the progression of the draft to
> RFC, please articulate your concern. If you support it, please indicate that
> you have read the latest version and it is ready for publication in your
> opinion. As always, review comments and nits are most welcome.
>

---

From: Siva Sivabalan <[email-masked]>
Date: Sun, 20 Sep 2020 08:12:16 -0400

Support as a co-author.

Thanks,
Siva

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 21 Sep 2020 10:16:46 +0800

HI, Dhruv and the authors this draft:

How to ensure the interoperability? The document just says:
"Further, if one or more parameters received in the POLICY-PARAMETERS-TLV received by the PCEP speaker are considered as unacceptable in the context of the
   associated policy (e.g. out of range value, badly encoded value...), the PCEP speaker MUST NOT apply the received policy and SHOULD log this event."
There will be no more detail error information can be reported via such opaque policy. How to debug the policy deployment then?

And, if there are some examples to show what association requirements can't be accomplished by the SVEC object, and can only be done via PAG, the document may be more convincible.

Best Regards

Aijun Wang
China Telecom 

-----Original Message-----
From: Dhruv Dhody [mailto:[email-masked]] 
Sent: Friday, September 18, 2020 12:40 PM
To: Aijun Wang <[email-masked]>
Cc: [email-masked]; [email-masked]; pce-chairs <[email-masked]>
Subject: Re: [Pce] WGLC for draft-ietf-pce-association-policy

Hi Aijun,

I wanted to focus on the 3rd point. I remember this being discussed perhaps in the previous incarnation of the draft. The main motivation in PCEP is to provide a "standard" container and mechanism to associate (and encode the policy) and leave the actual policy standardization out of the scope of PCEP.

Another way to look at this would be, when a policy is well-known and needs to be standardized (some may consider diversity or SR-Policy as those policies), we define a new standard association-type for it with a standard TLV. This I-D is used when we do not have a standard policy defined in PCEP but would like to use the protocol as an opaque container to associate policies to the path. What does that policy mean and how to encode/decode the policy parameters are expected to be done out-of-band via other mechanisms which are better suited for policy definitions and configurations at the PCEP speakers.  Hope this helps!

Thanks!
Dhruv (hat-less!)

On Fri, Sep 18, 2020 at 6:43 AM Aijun Wang <[email-masked]> wrote:
> 1. This draft defines one new association type (policy association 
> type) that follows the procedures described in RFC8697 and attached 
> TLV? Is it right?
> association type, the related draft should clarify its relationship 
> between the SVEC object, if any.
> 3. For the definition of "Policy-Parameters-TLV", the "Policy 
> Parameters" is opaque value to the PCEP peers.  The draft describes 
> the PCEP peers should know how to the encoding format of such policy 
> in advance. But from my POV, the encoding format is the main content 
> needs to be standardized. If such contents can't be standardized, what 
> benefit can we get from this standardization work? What's the reason not to standardize this?
>
>
> Best Regards
>
> Aijun Wang
> China Telecom
>
>
> From: [email-masked] [mailto:[email-masked]] On Behalf Of 
> Dhruv Dhody
> others (internal and external to IETF) to determine 
> interest/participation level in our standards process.
> >
> > o Please review ideas from your peers, these are community outputs 
> > of the
> > please indicate that you have read the latest version and it is 
> > ready for publication in your opinion. As always, review comments 
> > and nits are most welcome.
> >

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Mon, 21 Sep 2020 08:03:35 +0000

Hi,

I have read this draft, and I support this document being published as an RFC.

Just a few nits are found and listed as below.

1. "may instantiate LSPs and specifies" -> "...specify"
2. "[RFC8697] specify" -> "... specifies"
3. "Error- Value 4" -> "Error-Value 4"
4. " In some cases to apply a PCE policy successfully, it is required to also associate some policy parameters that needs to be evaluated, to successfully apply the said policy. " 
-> " In some cases to apply a PCE policy successfully, it is required to also associate some policy parameters that need to be evaluated. "
5. "The TLV could include one or more policy related parameter" -> "... parameters"
6. "a 4-bytes alignment" -> "4-byte"
7. "The PCEP peer implementation need to be aware" 
->" The PCEP peer implementation needs to be aware"
8. "Further, if one or more parameters received in the POLICY-PARAMETERS-TLV received by the PCEP speaker "
-> "Further, if one or more parameters in the POLICY-PARAMETERS-TLV received by the PCEP speaker "
9. " IANA is requested to confirm the early-allocated codepoints "
-> " IANA is requested to confirm the early-allocated code point" 
10. "in which case the an operator MUST "
-> " in which case the operator MUST "
11. "This module supports associations as defined in [RFC8697] and thus support the Policy Association groups "
-> "This module supports associations as defined in [RFC8697] and thus supports the Policy Association groups "
12. " this document borrow some of " -> " this document borrowed some of "

Best regards,
Shuping

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 21 Sep 2020 16:34:21 +0530

Hi Aijun,

See inline...

> There will be no more detail error information can be reported via such opaque policy. How to debug the policy deployment then?

I agree, it would be wise to generate an error, we could reuse the
error from RFC 8697.  How about ->

   Further, if one or more
   parameters received in the POLICY-PARAMETERS-TLV received by the PCEP
   speaker are considered as unacceptable in the context of the
   associated policy (e.g. out of range value, badly encoded value...),
   the PCEP speaker MUST reject the PCEP
   message and send a PCErr message with Error-Type 26 "Association
   Error" and Error-Value 5 "Operator-configured association information
   mismatch"  [RFC8697]. PCEP speaker SHOULD log this event.

> And, if there are some examples to show what association requirements can't be accomplished by the SVEC object, and can only be done via PAG, the document may be more convincible.

SVEC object has an impact only on the diversity association and it was
covered in https://www.rfc-editor.org/rfc/rfc8800.html#name-relationship-to-svec.
Your suggestion to add an example is a good idea. Can the authors
consider adding something in the appendix?

Thanks!
Dhruv [ still without hats :) ]

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 22 Sep 2020 01:14:48 +0000

Hi,

I've read the latest version of this document, and think it is ready for publication. 

Best regards,
Jie

> This email starts a working group last call for draft-ietf-pce-association-policy
> [1].  Please indicate your support or concern for this draft. If you are opposed
> to the progression of the draft to RFC, please articulate your concern. If you
> support it, please indicate that you have read the latest version and it is ready
> for publication in your opinion. As always, review comments and nits are most
> welcome.
>

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 22 Sep 2020 09:36:56 +0800

Hi, Dhruv:

Reusing "Association Error/Operator-configured association information mismatch" can give some clues, but it does not yet hit the crucial point.
The content of this draft has illustrated some possible reasons ---(e.g. out of range value, badly encoded value...),  but the returned error information blends them together again.
Can we define some new error-value to reflect them more clearly? I think the parser of the association policy can give the detail information.

And, seems no authors of this draft to response these questions?

Best Regards

Aijun Wang
China Telecom 

-----Original Message-----
From: Dhruv Dhody [mailto:[email-masked]] 
Sent: Monday, September 21, 2020 7:04 PM
To: Aijun Wang <[email-masked]>
Cc: [email-masked]; [email-masked]; pce-chairs <[email-masked]>
Subject: Re: [Pce] WGLC for draft-ietf-pce-association-policy

Hi Aijun,

See inline...

> There will be no more detail error information can be reported via such opaque policy. How to debug the policy deployment then?

I agree, it would be wise to generate an error, we could reuse the error from RFC 8697.  How about ->

   Further, if one or more

> And, if there are some examples to show what association requirements can't be accomplished by the SVEC object, and can only be done via PAG, the document may be more convincible.

SVEC object has an impact only on the diversity association and it was covered in https://www.rfc-editor.org/rfc/rfc8800.html#name-relationship-to-svec.
Your suggestion to add an example is a good idea. Can the authors consider adding something in the appendix?

Thanks!

> > needs to be standardized. If such contents can't be standardized, 
> > what benefit can we get from this standardization work? What's the reason not to standardize this?
> >
> >
> > Best Regards
> >
> > Aijun Wang
> > China Telecom
> >
> >
> > From: [email-masked] [mailto:[email-masked]] On Behalf 
> > Of Dhruv Dhody
> > [https://www.ietf.org/proceedings/108/slides/slides-108-pce-1-introd
> > uc
> > tion-0
> > 1]
> >
> > > Please be Vocal
> > >
> > > draft-ietf-pce-association-policy [1].  Please indicate your 
> > > support or concern for this draft. If you are opposed to the 
> > > progression of the draft to RFC, please articulate your concern. 
> > > If you support it, please indicate that you have read the latest 
> > > version and it is ready for publication in your opinion. As 
> > > always, review comments and nits are most welcome.
> > >

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 22 Sep 2020 00:50:23 -0400

I support advancement of this critical draft.

This draft provides a extensibility of existing generic mechanism of
creating a groupings of LSPs to define associations between a set of LSPs
and configuration attributes with stateful and stateless PCE described in
RFC 8697 by mapping one or more LSPs with policy.

Thanks

Gyan

On Mon, Sep 21, 2020 at 9:37 PM Aijun Wang <[email-masked]>
wrote:

> Hi, Dhruv:
>
>
>
> Reusing "Association Error/Operator-configured association information
> mismatch" can give some clues, but it does not yet hit the crucial point.
>
> The content of this draft has illustrated some possible reasons ---(e.g.
> out of range value, badly encoded value...),  but the returned error
> information blends them together again.
>
> Can we define some new error-value to reflect them more clearly? I think
> the parser of the association policy can give the detail information.
>
>
>
> > "Further, if one or more parameters received in the
> POLICY-PARAMETERS-TLV received by the PCEP speaker are considered as
> unacceptable in the context of the
>
> the PCEP speaker MUST NOT apply the received policy and SHOULD log this
> event."
>
> > There will be no more detail error information can be reported via such
> opaque policy. How to debug the policy deployment then?
>
> >
>
>
>
> > And, if there are some examples to show what association requirements
> can't be accomplished by the SVEC object, and can only be done via PAG, the
> document may be more convincible.
>
> >
>
>
>
> covered in
> https://www.rfc-editor.org/rfc/rfc8800.html#name-relationship-to-svec.
>
> > Cc: [email-masked]; [email-masked];
>
> > pce-chairs <[email-masked]>
>
> perhaps in the previous incarnation of the draft. The main motivation in
> PCEP is to provide a "standard" container and mechanism to associate (and
> encode the policy) and leave the actual policy standardization out of the
> scope of PCEP.
>
> >
>
> needs to be standardized (some may consider diversity or SR-Policy as those
> policies), we define a new standard association-type for it with a standard
> TLV. This I-D is used when we do not have a standard policy defined in PCEP
> but would like to use the protocol as an opaque container to associate
> policies to the path. What does that policy mean and how to encode/decode
> the policy parameters are expected to be done out-of-band via other
> mechanisms which are better suited for policy definitions and
> configurations at the PCEP speakers.  Hope this helps!
>
> >
>
> > Thanks!
>
> > Dhruv (hat-less!)
>
> >
>
> > > I Just have a quick view of this draft, and has some points wanted
>
> > > to be
>
> > > clarified:
>
> > > > o The working group mailing lists are looked at by the IESG, IAB,
>
> > > > and
>
> > > > https://datatracker.ietf.org/doc/draft-ietf-pce-association-policy
>
> > > > /
>
> > >
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 24 Sep 2020 15:57:18 +0530

Hi WG,

The WG LC is closed, we have support to move the document along the
publication process. Thanks to everyone who responded. Hari has agreed to
shepherd this I-D. (Thanks Hari!)

Authors,

Please post an update, handling all comments received.

Thanks!
Dhruv & Julien

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Tue, 29 Sep 2020 08:54:42 +0000

Hi Aijun,

We just posted a new revision to address your comments. Please check the update. https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-association-policy-12

As per your suggestion, new error-codes and examples in the appendix are added.

Many thanks for your comments!
Cheng

-----Original Message-----
From: Aijun Wang [mailto:[email-masked]] 
Sent: Tuesday, September 22, 2020 9:37 AM
To: 'Dhruv Dhody' <[email-masked]>
Cc: [email-masked]; [email-masked]; 'pce-chairs' <[email-masked]>
Subject: RE: [Pce] WGLC for draft-ietf-pce-association-policy

Hi, Dhruv:

Best Regards

Aijun Wang
China Telecom 

-----Original Message-----
From: Dhruv Dhody [mailto:[email-masked]]
Sent: Monday, September 21, 2020 7:04 PM
To: Aijun Wang <[email-masked]>
Cc: [email-masked]; [email-masked]; pce-chairs <[email-masked]>
Subject: Re: [Pce] WGLC for draft-ietf-pce-association-policy

Hi Aijun,

See inline...

   Further, if one or more

Thanks!

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Tue, 29 Sep 2020 08:55:58 +0000

Hi Shuping,

Many thanks for your comments! We have updated the document to address them. Please check the diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-association-policy-12

Thanks again for your comments!
Cheng

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of Pengshuping (Peng Shuping)
Sent: Monday, September 21, 2020 4:04 PM
To: Dhruv Dhody <[email-masked]>; [email-masked]
Cc: [email-masked]; pce-chairs <[email-masked]>
Subject: Re: [Pce] WGLC for draft-ietf-pce-association-policy

Hi,

Best regards,
Shuping

> for publication in your opinion. As always, review comments and nits are most welcome.
>