Re: [Pce] WG Last Call for draft-ietf-pce-pcep-yang-19

2023-03-06 Thread Dhruv Dhody 
Hi again again :)

On Mon, Nov 28, 2022 at 6:32 PM tom petch  wrote:

> From: Pce  on behalf of tom petch <
> ie...@btconnect.com>
> Sent: 25 November 2022 13:11
>
> 
>
> Some final (hopefully:-) stray thoughts on -20 after looking at RFC8231
>
> typedef sync-state
> the states seem intuitively plausible but do not seem to be described as
> such in RFC8231, RFC8232 etc
>
>
Yes, it is quite intuitive, especially if you look at the figures in the
RFCs with "sync start" and "sync done" as marked!



> extended tunnel id
> is modelled as an ip-address.  RFC3209 says 'normally all zeros' but the
> canonical form of an address includes seperators so I am unsure if that
> allows for all zeros.
>
>
Added this text - "The all-zeros format is represented as 0.0.0.0 and ::."



> container initiation
> leaf peer
> I do not understand
> 'At the PCE, the
> reference to the PCEP peer where the LSP
> is initiated";
> '
>

Updated to ->

  description
"If the role is PCC, this leaf refer to the PCEP
 peer (PCE) that initiated this LSP. If the role
 is PCE, this leaf refer to the PCEP peer (PCC)
 where the LSP is initiated";

Thanks!
Dhruv



> Tom Petch
>
> Some more thoughts on -20
>
> RFC5520 says that reuse timer MUST NOT reuse for at  least 30min;  YANG
> has a default of 30min should that be a minimum?
>
> Path Setup Type v Path Signaling Type
> PCE mostly uses the former, TEAS te-types uses the latter.  Is there a
> difference?  Worth an explanatory note (some WG use ... which some may find
> confusing:-) IMHO
>
> ASSOCIATION Type
> somewhat similar; this I-D uses te-types but there is also an IANA
> registry.  Are they the same ?  I see IANA being updated much more quickly
> than a YANG module such as te-types in which case I think that the
> reference perhaps should be to the IANA registry.
>
> The identifiers used for lsp-error are not quite the same as those in
> RFC8231.  Yes the order is the same so I can work it out but would prefer
> either the names to be the same or else - probably better - have the
> numeric values included in description of the identity
>
> I am almost done but not quite  - I am trying to match 8231 with the YANG
> and have not quite made it but is is CoB on Friday afternoon:-(
>
> Tom Petch
> ____
> From: Pce  on behalf of tom petch <
> ie...@btconnect.com>
> Sent: 22 November 2022 12:19
> To: julien.meu...@orange.com; pce@ietf.org
> Subject: Re: [Pce] WG Last Call for draft-ietf-pce-pcep-yang-19
>
> From: Pce  on behalf of tom petch <
> ie...@btconnect.com>
> Sent: 17 November 2022 10:42
>
> From: Pce  on behalf of julien.meu...@orange.com <
> julien.meu...@orange.com>
> Sent: 17 November 2022 09:38
>
> As mentioned in the PCE session during IETF 115, this WGLC has ended.
> Thanks Tom for your review. Comment resolution is in progress.
>
> 
>
> -20 did appear in October.  Is that worth looking at or waiting for -21?
>
> 
>
> Sigh, it is big, it is complicated and one day I will get to review it
> all, but not just yet.
>
> MSD. Treated here as a single value but other I-D now treat it as a list
> of different types as in draft-qu-mpls-mpls-msd-yang and there is an IANA
> registry of types as well as differentiation between node and link MSD.
> Which does PCE mean?  Or should it join the crowd and have lists thereof?
>
> -20 changes the reference for the IANA PCE flags.  This change to IANA is
> by draft-ietf-lsr-pce-discovery-security-support-13 so I see that I-D as a
> Normative Reference.
>
> -20 adds two new flags.  TCP-AO I see in the flags but nowhere else, no
> reference, no feature, no explanation.  Something needs adding and I would
> expect that to include Security Considerations.  Again this makes that
> lsr-pce I-D a Normative Reference IMO.
>
> p.11 Tree diagram seems to be missing a  vertical bar where auth has been
> slotted in
>
> "Set to true if SR-MPLS is enabled
> but where is this enablement?  Not in RFC8664 AFAICT
>
>   "PCEP Association Global Source.";
> I see
>  "PCEP Global Association Source.";
>   In RFC8697
>
> [IANA-IGP] reference
> Title seems short of a 'P'
>
>
> Tom Petch
>
>
> Regards,
>
> Julien
>
>
> On 26/09/2022 15:01, julien.meu...@orange.com wrote:
> > Hi PCE WG,
> >
> > This message starts a 2-week WG Last Call for
> > draft-ietf-pce-pcep-yang-19. Please review and share any

Re: [Pce] WG Last Call for draft-ietf-pce-pcep-yang-19

2023-03-06 Thread Dhruv Dhody 
Hi again Tom!

Thanks for your detailed reviews! Much appreciated!


On Fri, Nov 25, 2022 at 6:42 PM tom petch  wrote:

> Some more thoughts on -20
>
> RFC5520 says that reuse timer MUST NOT reuse for at  least 30min;  YANG
> has a default of 30min should that be a minimum?
>
>
Agree added range "30..max";



> Path Setup Type v Path Signaling Type
> PCE mostly uses the former, TEAS te-types uses the latter.  Is there a
> difference?  Worth an explanatory note (some WG use ... which some may find
> confusing:-) IMHO
>
>
In PCE WG documents use of the term Path Setup Type (PST) is uniform;
anyways I have added a note in the description.



> ASSOCIATION Type
> somewhat similar; this I-D uses te-types but there is also an IANA
> registry.  Are they the same ?  I see IANA being updated much more quickly
> than a YANG module such as te-types in which case I think that the
> reference perhaps should be to the IANA registry.
>
>
There are some PCEP specific association types that are now added. The
reference to IANA exists already.



> The identifiers used for lsp-error are not quite the same as those in
> RFC8231.  Yes the order is the same so I can work it out but would prefer
> either the names to be the same or else - probably better - have the
> numeric values included in description of the identity
>
>
Updated.

Thanks!
Dhruv



> I am almost done but not quite  - I am trying to match 8231 with the YANG
> and have not quite made it but is is CoB on Friday afternoon:-(
>
> Tom Petch
> 
> From: Pce  on behalf of tom petch <
> ie...@btconnect.com>
> Sent: 22 November 2022 12:19
> To: julien.meu...@orange.com; pce@ietf.org
> Subject: Re: [Pce] WG Last Call for draft-ietf-pce-pcep-yang-19
>
> From: Pce  on behalf of tom petch <
> ie...@btconnect.com>
> Sent: 17 November 2022 10:42
>
> From: Pce  on behalf of julien.meu...@orange.com <
> julien.meu...@orange.com>
> Sent: 17 November 2022 09:38
>
> As mentioned in the PCE session during IETF 115, this WGLC has ended.
> Thanks Tom for your review. Comment resolution is in progress.
>
> 
>
> -20 did appear in October.  Is that worth looking at or waiting for -21?
>
> 
>
> Sigh, it is big, it is complicated and one day I will get to review it
> all, but not just yet.
>
> MSD. Treated here as a single value but other I-D now treat it as a list
> of different types as in draft-qu-mpls-mpls-msd-yang and there is an IANA
> registry of types as well as differentiation between node and link MSD.
> Which does PCE mean?  Or should it join the crowd and have lists thereof?
>
> -20 changes the reference for the IANA PCE flags.  This change to IANA is
> by draft-ietf-lsr-pce-discovery-security-support-13 so I see that I-D as a
> Normative Reference.
>
> -20 adds two new flags.  TCP-AO I see in the flags but nowhere else, no
> reference, no feature, no explanation.  Something needs adding and I would
> expect that to include Security Considerations.  Again this makes that
> lsr-pce I-D a Normative Reference IMO.
>
> p.11 Tree diagram seems to be missing a  vertical bar where auth has been
> slotted in
>
> "Set to true if SR-MPLS is enabled
> but where is this enablement?  Not in RFC8664 AFAICT
>
>   "PCEP Association Global Source.";
> I see
>  "PCEP Global Association Source.";
>   In RFC8697
>
> [IANA-IGP] reference
> Title seems short of a 'P'
>
>
> Tom Petch
>
>
> Regards,
>
> Julien
>
>
> On 26/09/2022 15:01, julien.meu...@orange.com wrote:
> > Hi PCE WG,
> >
> > This message starts a 2-week WG Last Call for
> > draft-ietf-pce-pcep-yang-19. Please review and share any feedback
> > using the PCE mailing list.
> > This WGLC will end on Tuesday October 11.
> >
> > Thanks,
> >
> > Julien
>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Last Call for draft-ietf-pce-pcep-yang-19

2023-03-06 Thread Dhruv Dhody 
Hi Tom,

Thanks for your further comments!

On Tue, Nov 22, 2022 at 5:49 PM tom petch  wrote:

> From: Pce  on behalf of tom petch <
> ie...@btconnect.com>
> Sent: 17 November 2022 10:42
>
> From: Pce  on behalf of julien.meu...@orange.com <
> julien.meu...@orange.com>
> Sent: 17 November 2022 09:38
>
> As mentioned in the PCE session during IETF 115, this WGLC has ended.
> Thanks Tom for your review. Comment resolution is in progress.
>
> 
>
> -20 did appear in October.  Is that worth looking at or waiting for -21?
>
> 
>
> Sigh, it is big, it is complicated and one day I will get to review it
> all, but not just yet.
>
> MSD. Treated here as a single value but other I-D now treat it as a list
> of different types as in draft-qu-mpls-mpls-msd-yang and there is an IANA
> registry of types as well as differentiation between node and link MSD.
> Which does PCE mean?  Or should it join the crowd and have lists thereof?
>
>
In PCEP we have only one field to carry MSD as per RFC 8664 and its
description is clear in that RFC. draft-ietf-mpls-msd also defined
msd-ERLD which is not carried in PCEP and same with link MSD. I don't think
we need to make any further changes here!



> -20 changes the reference for the IANA PCE flags.  This change to IANA is
> by draft-ietf-lsr-pce-discovery-security-support-13 so I see that I-D as a
> Normative Reference.
>
>
Ack.



> -20 adds two new flags.  TCP-AO I see in the flags but nowhere else, no
> reference, no feature, no explanation.  Something needs adding and I would
> expect that to include Security Considerations.  Again this makes that
> lsr-pce I-D a Normative Reference IMO.
>
>
Ack.



> p.11 Tree diagram seems to be missing a  vertical bar where auth has been
> slotted in
>
>
Ack



> "Set to true if SR-MPLS is enabled
> but where is this enablement?  Not in RFC8664 AFAICT
>
>
RFC 8664 states ->

Implementations MUST allow the operator to enable and disable the Segment
Routing path setup type on a PCEP-speaking device.

Note that it is done via the RFC 8408 mechanism.



>   "PCEP Association Global Source.";
> I see
>  "PCEP Global Association Source.";
>   In RFC8697
>
>
Ack



> [IANA-IGP] reference
> Title seems short of a 'P'
>
>
Ack

Please see the new update for the I-D posted -
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-yang/
Diff - https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-pcep-yang-21


Thanks!
Dhruv

>
> Tom Petch
>
>
> Regards,
>
> Julien
>
>
> On 26/09/2022 15:01, julien.meu...@orange.com wrote:
> > Hi PCE WG,
> >
> > This message starts a 2-week WG Last Call for
> > draft-ietf-pce-pcep-yang-19. Please review and share any feedback
> > using the PCE mailing list.
> > This WGLC will end on Tuesday October 11.
> >
> > Thanks,
> >
> > Julien
>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Last Call for draft-ietf-pce-pcep-yang-19

2022-11-28 Thread tom petch 
From: Pce  on behalf of tom petch 
Sent: 25 November 2022 13:11



Some final (hopefully:-) stray thoughts on -20 after looking at RFC8231

typedef sync-state
the states seem intuitively plausible but do not seem to be described as such 
in RFC8231, RFC8232 etc

extended tunnel id 
is modelled as an ip-address.  RFC3209 says 'normally all zeros' but the 
canonical form of an address includes seperators so I am unsure if that allows 
for all zeros.

container initiation
leaf peer
I do not understand 
'At the PCE, the
reference to the PCEP peer where the LSP
is initiated";
'
Tom Petch

Some more thoughts on -20

RFC5520 says that reuse timer MUST NOT reuse for at  least 30min;  YANG has a 
default of 30min should that be a minimum?

Path Setup Type v Path Signaling Type
PCE mostly uses the former, TEAS te-types uses the latter.  Is there a 
difference?  Worth an explanatory note (some WG use ... which some may find 
confusing:-) IMHO

ASSOCIATION Type
somewhat similar; this I-D uses te-types but there is also an IANA registry.  
Are they the same ?  I see IANA being updated much more quickly than a YANG 
module such as te-types in which case I think that the reference perhaps should 
be to the IANA registry.

The identifiers used for lsp-error are not quite the same as those in RFC8231.  
Yes the order is the same so I can work it out but would prefer either the 
names to be the same or else - probably better - have the numeric values 
included in description of the identity

I am almost done but not quite  - I am trying to match 8231 with the YANG and 
have not quite made it but is is CoB on Friday afternoon:-(

Tom Petch

From: Pce  on behalf of tom petch 
Sent: 22 November 2022 12:19
To: julien.meu...@orange.com; pce@ietf.org
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-pcep-yang-19

From: Pce  on behalf of tom petch 
Sent: 17 November 2022 10:42

From: Pce  on behalf of julien.meu...@orange.com 

Sent: 17 November 2022 09:38

As mentioned in the PCE session during IETF 115, this WGLC has ended.
Thanks Tom for your review. Comment resolution is in progress.



-20 did appear in October.  Is that worth looking at or waiting for -21?



Sigh, it is big, it is complicated and one day I will get to review it all, but 
not just yet.

MSD. Treated here as a single value but other I-D now treat it as a list of 
different types as in draft-qu-mpls-mpls-msd-yang and there is an IANA registry 
of types as well as differentiation between node and link MSD.  Which does PCE 
mean?  Or should it join the crowd and have lists thereof?

-20 changes the reference for the IANA PCE flags.  This change to IANA is by 
draft-ietf-lsr-pce-discovery-security-support-13 so I see that I-D as a 
Normative Reference.

-20 adds two new flags.  TCP-AO I see in the flags but nowhere else, no 
reference, no feature, no explanation.  Something needs adding and I would 
expect that to include Security Considerations.  Again this makes that lsr-pce 
I-D a Normative Reference IMO.

p.11 Tree diagram seems to be missing a  vertical bar where auth has been 
slotted in

"Set to true if SR-MPLS is enabled
but where is this enablement?  Not in RFC8664 AFAICT

  "PCEP Association Global Source.";
I see
 "PCEP Global Association Source.";
  In RFC8697

[IANA-IGP] reference
Title seems short of a 'P'


Tom Petch


Regards,

Julien


On 26/09/2022 15:01, julien.meu...@orange.com wrote:
> Hi PCE WG,
>
> This message starts a 2-week WG Last Call for
> draft-ietf-pce-pcep-yang-19. Please review and share any feedback
> using the PCE mailing list.
> This WGLC will end on Tuesday October 11.
>
> Thanks,
>
> Julien

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Last Call for draft-ietf-pce-pcep-yang-19

2022-11-25 Thread tom petch 
Some more thoughts on -20

RFC5520 says that reuse timer MUST NOT reuse for at  least 30min;  YANG has a 
default of 30min should that be a minimum?

Path Setup Type v Path Signaling Type
PCE mostly uses the former, TEAS te-types uses the latter.  Is there a 
difference?  Worth an explanatory note (some WG use ... which some may find 
confusing:-) IMHO

ASSOCIATION Type
somewhat similar; this I-D uses te-types but there is also an IANA registry.  
Are they the same ?  I see IANA being updated much more quickly than a YANG 
module such as te-types in which case I think that the reference perhaps should 
be to the IANA registry.

The identifiers used for lsp-error are not quite the same as those in RFC8231.  
Yes the order is the same so I can work it out but would prefer either the 
names to be the same or else - probably better - have the numeric values 
included in description of the identity

I am almost done but not quite  - I am trying to match 8231 with the YANG and 
have not quite made it but is is CoB on Friday afternoon:-(

Tom Petch

From: Pce  on behalf of tom petch 
Sent: 22 November 2022 12:19
To: julien.meu...@orange.com; pce@ietf.org
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-pcep-yang-19

From: Pce  on behalf of tom petch 
Sent: 17 November 2022 10:42

From: Pce  on behalf of julien.meu...@orange.com 

Sent: 17 November 2022 09:38

As mentioned in the PCE session during IETF 115, this WGLC has ended.
Thanks Tom for your review. Comment resolution is in progress.



-20 did appear in October.  Is that worth looking at or waiting for -21?



Sigh, it is big, it is complicated and one day I will get to review it all, but 
not just yet.

MSD. Treated here as a single value but other I-D now treat it as a list of 
different types as in draft-qu-mpls-mpls-msd-yang and there is an IANA registry 
of types as well as differentiation between node and link MSD.  Which does PCE 
mean?  Or should it join the crowd and have lists thereof?

-20 changes the reference for the IANA PCE flags.  This change to IANA is by 
draft-ietf-lsr-pce-discovery-security-support-13 so I see that I-D as a 
Normative Reference.

-20 adds two new flags.  TCP-AO I see in the flags but nowhere else, no 
reference, no feature, no explanation.  Something needs adding and I would 
expect that to include Security Considerations.  Again this makes that lsr-pce 
I-D a Normative Reference IMO.

p.11 Tree diagram seems to be missing a  vertical bar where auth has been 
slotted in

"Set to true if SR-MPLS is enabled
but where is this enablement?  Not in RFC8664 AFAICT

  "PCEP Association Global Source.";
I see
 "PCEP Global Association Source.";
  In RFC8697

[IANA-IGP] reference
Title seems short of a 'P'


Tom Petch


Regards,

Julien


On 26/09/2022 15:01, julien.meu...@orange.com wrote:
> Hi PCE WG,
>
> This message starts a 2-week WG Last Call for
> draft-ietf-pce-pcep-yang-19. Please review and share any feedback
> using the PCE mailing list.
> This WGLC will end on Tuesday October 11.
>
> Thanks,
>
> Julien

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Last Call for draft-ietf-pce-pcep-yang-19

2022-11-22 Thread tom petch 
From: Pce  on behalf of tom petch 
Sent: 17 November 2022 10:42

From: Pce  on behalf of julien.meu...@orange.com 

Sent: 17 November 2022 09:38

As mentioned in the PCE session during IETF 115, this WGLC has ended.
Thanks Tom for your review. Comment resolution is in progress.



-20 did appear in October.  Is that worth looking at or waiting for -21?



Sigh, it is big, it is complicated and one day I will get to review it all, but 
not just yet.

MSD. Treated here as a single value but other I-D now treat it as a list of 
different types as in draft-qu-mpls-mpls-msd-yang and there is an IANA registry 
of types as well as differentiation between node and link MSD.  Which does PCE 
mean?  Or should it join the crowd and have lists thereof?

-20 changes the reference for the IANA PCE flags.  This change to IANA is by 
draft-ietf-lsr-pce-discovery-security-support-13 so I see that I-D as a 
Normative Reference.

-20 adds two new flags.  TCP-AO I see in the flags but nowhere else, no 
reference, no feature, no explanation.  Something needs adding and I would 
expect that to include Security Considerations.  Again this makes that lsr-pce 
I-D a Normative Reference IMO.

p.11 Tree diagram seems to be missing a  vertical bar where auth has been 
slotted in

"Set to true if SR-MPLS is enabled
but where is this enablement?  Not in RFC8664 AFAICT

  "PCEP Association Global Source.";
I see
 "PCEP Global Association Source.";
  In RFC8697 

[IANA-IGP] reference
Title seems short of a 'P'


Tom Petch


Regards,

Julien


On 26/09/2022 15:01, julien.meu...@orange.com wrote:
> Hi PCE WG,
>
> This message starts a 2-week WG Last Call for
> draft-ietf-pce-pcep-yang-19. Please review and share any feedback
> using the PCE mailing list.
> This WGLC will end on Tuesday October 11.
>
> Thanks,
>
> Julien

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Last Call for draft-ietf-pce-pcep-yang-19

2022-11-17 Thread tom petch 
From: Pce  on behalf of julien.meu...@orange.com 

Sent: 17 November 2022 09:38

As mentioned in the PCE session during IETF 115, this WGLC has ended.
Thanks Tom for your review. Comment resolution is in progress.



-20 did appear in October.  Is that worth looking at or waiting for -21?

Tom Petch


Regards,

Julien


On 26/09/2022 15:01, julien.meu...@orange.com wrote:
> Hi PCE WG,
>
> This message starts a 2-week WG Last Call for
> draft-ietf-pce-pcep-yang-19. Please review and share any feedback
> using the PCE mailing list.
> This WGLC will end on Tuesday October 11.
>
> Thanks,
>
> Julien



___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Last Call for draft-ietf-pce-pcep-yang-19

2022-11-17 Thread julien.meuric 

Hi all,

As mentioned in the PCE session during IETF 115, this WGLC has ended. 
Thanks Tom for your review. Comment resolution is in progress.


Regards,

Julien


On 26/09/2022 15:01, julien.meu...@orange.com wrote:

Hi PCE WG,

This message starts a 2-week WG Last Call for 
draft-ietf-pce-pcep-yang-19. Please review and share any feedback 
using the PCE mailing list.

This WGLC will end on Tuesday October 11.

Thanks,

Julien





smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Last Call for draft-ietf-pce-pcep-yang-19

2022-10-23 Thread Dhruv Dhody 
Hi Tom,

Thanks for your detailed review!

On Thu, Oct 6, 2022 at 5:13 PM tom petch  wrote:

> From: Pce  on behalf of julien.meu...@orange.com <
> julien.meu...@orange.com>
> Sent: 26 September 2022 14:01
>
> This message starts a 2-week WG Last Call for
> draft-ietf-pce-pcep-yang-19. Please review and share any feedback using
> the PCE mailing list.
> This WGLC will end on Tuesday October 11.
>
> 
> I commented before that this has  inadequate security since it mandates
> TLS1.3 where early data opens the door to all sorts of nasties.  Here are
> my other comments.
>
>
I have added this text ->

   [RFC8253] describes the use of TLSv1.2 [RFC5246] or later in PCEP.
   Further, [I-D.dhody-pce-pceps-tls13] specify how to protect PCEP
   messages with TLS 1.3 [RFC8446] by disallowing the use of early data
   (0-RTT) and listing the cipher suites that need to be supported with
   TLS 1.3.

...

   The YANG module uses the TLS grouping in
   [I-D.ietf-netconf-tls-client-server].  Note that any TLS version can
   be configured but [I-D.ietf-netconf-tls-client-server] recommends the
   use of TLS 1.3 only.  At the time of publication of this document,
   TLS 1.2 is still in common use for PCEP and can still be enabled with
   feature "tls12" even though it is marked with status as
   "deprecated".

I hope with this we can make progress.



> pce-pcep-stateful-pce-gmpls I think is now RFC8779
>
>
Ack



> s.4.1.1.1 just one List I see
>
>
Updated



> s.6.1 the list is also keyed on lsp-id
>
>
Added



> The YANG module has lower case must/should; is this intended?
>
>
I checked, the usage seems to be okay as they are describing the base
protocol handling and not related to YANG elements



> The timer names are not those of RFC5440 - perhaps worth a note giving the
> mapping even if it is only hyphen-minus
>
> container SR
> set to true if SR is enabled
> Where is that enabled, for what scope?
>
> likewise msd; other I-D decompose MSD three ways on a per signalling
> basis, I am not clear which MSD applies here.  A bit like MTU, it  might
> need a context to be clear.
>
>
Updated.



> The reference for path-key looks like it is a line too long
>
>
Ack



> RFC8231 says srp-id  is reserved in which case the range should
> not be ..max; this was correct in -18
>
>
Oops! Fixed!



> I do not understand the use of must + error-message for config false.  I
> am used to it for validating an update and cannot see when this message
> will be generated.  This occurs in a number of places.
>
>
https://www.rfc-editor.org/rfc/rfc7950.html#section-7.5.3 says "The
constraint
   is enforced according to the rules in Section 8
."

where https://www.rfc-editor.org/rfc/rfc7950.html#section-8.1 says "If the
constraint is defined on state data, it MUST be true in a
  valid state data tree."

I did not see any guidance on what happens with error-message in this case.
I have kept this comment pending for now. I will check with YANG experts!


> RPC often have a nacm default-deny-all
>
>
Added



> s.9
> The YANG modules   .../is/are/
>
>
Ack

I have posted an updated version -
https://www.ietf.org/archive/id/draft-ietf-pce-pcep-yang-20.html

Thanks!
Dhruv



> Tom Petch
>
>
> Thanks,
>
> Julien
>
>
>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Last Call for draft-ietf-pce-pcep-yang-19

2022-10-07 Thread tom petch 
From: Dhruv Dhody 
Sent: 07 October 2022 10:45

Hi Tom, WG,

I was about to send a note to the WG but you beat me to it. You made a valid 
point regarding TLS 1.3. But I suggest a different approach.

RFC 8253 states that TLS v1.2 or "later" is supported for PCEP. IMHO, a draft 
fixing the issues with TLS 1.3 for PCEPS is a much better idea than saying no 
TLS 1.3. Sean, Russ and I published - 
https://www.ietf.org/id/draft-dhody-pce-pceps-tls13-00.html. Note that a 
similar effort is also being made in NetConf WG.

Coming to the PCEP-YANG, I plan to add a section in the draft that would talk 
about how to enable TLS 1.2 and TLS 1.3 for PCEP. Thoughts?


 I think that the current txt in -19 is unclear, misleading perhaps.
PCEP over TLS references RFC8253 which is fine but then mentions 8446 which is 
not fine since there is no caveat about early data and such like; and the 
netconf-tls import is categoric TLS1,3 or else - TLS1.2 is NOT RECOMMENDED. 
 I think that Netconf is not helpful here -  TLS1.2 is going to be used for 
years, embedded devices, network boxes and such like and is fit for purpose 
even if cryptoananlysts can find weaknesses therein.  I think then that 
protocols like PCE have a problem and would say the TLS1.3 is under 
consideration.  If the IESG will not accept that, then your new I-D will be 
needed, as a Normative Reference..  
 

I have seen statements in other WG to the effect that of course TLS1.2 is just 
fine and we have no intention of doing anything else and one such I-D is past 
the IESG.

Meanwhile I note the 'How to ... over 13' I-Ds and wish I had written one as I 
intended in March:-(

Tom Petch

Thanks!
Dhruv (co-author hat on, co-chair hat off)

On Fri, Oct 7, 2022 at 2:25 PM tom petch 
mailto:ie...@btconnect.com>> wrote:
From: Pce mailto:pce-boun...@ietf.org>> on behalf of tom 
petch mailto:ie...@btconnect.com>>
Sent: 03 October 2022 11:02

From: Pce mailto:pce-boun...@ietf.org>> on behalf of 
julien.meu...@orange.com 
mailto:julien.meu...@orange.com>>
Sent: 26 September 2022 14:01

Hi PCE WG,

This message starts a 2-week WG Last Call for
draft-ietf-pce-pcep-yang-19. Please review and share any feedback using
the PCE mailing list.
This WGLC will end on Tuesday October 11.


There are several little problems with this I-D, which I will post in due 
course, but one big one that I think needs outside assistance and will take 
time to resolve, namely the lack of security.

This imports netconf-tls groupings and the netconf  I-D says basically security 
is nothing to do with us, that is up to the user of the grouping.  It 
recommends TLS1.3 and says TLS1.2 is obsolete and not recommended.

Trouble is, for most users TLS1.3 is not recommended because it is insecure 
because it introduces new features which are fine for web access and dangerous 
for almost other cases (eg early data).  There are a number of IETF documents 
looking at this and nailing down all the things you must not do with TLS1.3 in 
an operational environment (which is what most of the IETF is about).  RFC9190 
section 2 is an example of what I mean but from tracking the evolution of that 
RFC I suspect that that got watered down by the supporters of TLS1.3.

This I-D needs the equivalent (or else a MUST NOT for TLS1.3!).  Many of those 
involved with security in the IETF will not understand the issue, how dangerous 
TLS1.3 is for anything other than web access.


I note the submission of draft-dhody ... TLS13.

I wonder what that plan is; for pcep-yang to ban TLS1.3 and have a reference to 
this I-D? or what?

I think that PSK need more treatment.  My take is that RFC8446 bans PSK except 
when used for resumption where a session has been set up using certificates.  I 
see two documents addressing this issue, - 9257, 9258 - but I have yet to read 
them.

Tom Petch


Tom Petch

Thanks,

Julien



___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Last Call for draft-ietf-pce-pcep-yang-19

2022-10-07 Thread Dhruv Dhody 
Hi Tom, WG,

I was about to send a note to the WG but you beat me to it. You made a
valid point regarding TLS 1.3. But I suggest a different approach.

RFC 8253 states that TLS v1.2 or "later" is supported for PCEP. IMHO, a
draft fixing the issues with TLS 1.3 for PCEPS is a much better idea than
saying no TLS 1.3. Sean, Russ and I published -
https://www.ietf.org/id/draft-dhody-pce-pceps-tls13-00.html. Note that a
similar effort is also being made in NetConf WG.

Coming to the PCEP-YANG, I plan to add a section in the draft that would
talk about how to enable TLS 1.2 and TLS 1.3 for PCEP. Thoughts?

Thanks!
Dhruv (co-author hat on, co-chair hat off)

On Fri, Oct 7, 2022 at 2:25 PM tom petch  wrote:

> From: Pce  on behalf of tom petch <
> ie...@btconnect.com>
> Sent: 03 October 2022 11:02
>
> From: Pce  on behalf of julien.meu...@orange.com <
> julien.meu...@orange.com>
> Sent: 26 September 2022 14:01
>
> Hi PCE WG,
>
> This message starts a 2-week WG Last Call for
> draft-ietf-pce-pcep-yang-19. Please review and share any feedback using
> the PCE mailing list.
> This WGLC will end on Tuesday October 11.
>
> 
> There are several little problems with this I-D, which I will post in due
> course, but one big one that I think needs outside assistance and will take
> time to resolve, namely the lack of security.
>
> This imports netconf-tls groupings and the netconf  I-D says basically
> security is nothing to do with us, that is up to the user of the grouping.
> It recommends TLS1.3 and says TLS1.2 is obsolete and not recommended.
>
> Trouble is, for most users TLS1.3 is not recommended because it is
> insecure because it introduces new features which are fine for web access
> and dangerous for almost other cases (eg early data).  There are a number
> of IETF documents looking at this and nailing down all the things you must
> not do with TLS1.3 in an operational environment (which is what most of the
> IETF is about).  RFC9190 section 2 is an example of what I mean but from
> tracking the evolution of that RFC I suspect that that got watered down by
> the supporters of TLS1.3.
>
> This I-D needs the equivalent (or else a MUST NOT for TLS1.3!).  Many of
> those involved with security in the IETF will not understand the issue, how
> dangerous TLS1.3 is for anything other than web access.
>
> 
> I note the submission of draft-dhody ... TLS13.
>
> I wonder what that plan is; for pcep-yang to ban TLS1.3 and have a
> reference to this I-D? or what?
>
> I think that PSK need more treatment.  My take is that RFC8446 bans PSK
> except when used for resumption where a session has been set up using
> certificates.  I see two documents addressing this issue, - 9257, 9258 -
> but I have yet to read them.
>
> Tom Petch
>
>
> Tom Petch
>
> Thanks,
>
> Julien
>
>
>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Last Call for draft-ietf-pce-pcep-yang-19

2022-10-07 Thread tom petch 
From: Pce  on behalf of tom petch 
Sent: 03 October 2022 11:02

From: Pce  on behalf of julien.meu...@orange.com 

Sent: 26 September 2022 14:01

Hi PCE WG,

This message starts a 2-week WG Last Call for
draft-ietf-pce-pcep-yang-19. Please review and share any feedback using
the PCE mailing list.
This WGLC will end on Tuesday October 11.


There are several little problems with this I-D, which I will post in due 
course, but one big one that I think needs outside assistance and will take 
time to resolve, namely the lack of security.

This imports netconf-tls groupings and the netconf  I-D says basically security 
is nothing to do with us, that is up to the user of the grouping.  It 
recommends TLS1.3 and says TLS1.2 is obsolete and not recommended.

Trouble is, for most users TLS1.3 is not recommended because it is insecure 
because it introduces new features which are fine for web access and dangerous 
for almost other cases (eg early data).  There are a number of IETF documents 
looking at this and nailing down all the things you must not do with TLS1.3 in 
an operational environment (which is what most of the IETF is about).  RFC9190 
section 2 is an example of what I mean but from tracking the evolution of that 
RFC I suspect that that got watered down by the supporters of TLS1.3.

This I-D needs the equivalent (or else a MUST NOT for TLS1.3!).  Many of those 
involved with security in the IETF will not understand the issue, how dangerous 
TLS1.3 is for anything other than web access.


I note the submission of draft-dhody ... TLS13.

I wonder what that plan is; for pcep-yang to ban TLS1.3 and have a reference to 
this I-D? or what?

I think that PSK need more treatment.  My take is that RFC8446 bans PSK except 
when used for resumption where a session has been set up using certificates.  I 
see two documents addressing this issue, - 9257, 9258 - but I have yet to read 
them.

Tom Petch


Tom Petch

Thanks,

Julien



___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Last Call for draft-ietf-pce-pcep-yang-19

2022-10-06 Thread tom petch 
From: Pce  on behalf of julien.meu...@orange.com 

Sent: 26 September 2022 14:01

This message starts a 2-week WG Last Call for
draft-ietf-pce-pcep-yang-19. Please review and share any feedback using
the PCE mailing list.
This WGLC will end on Tuesday October 11.


I commented before that this has  inadequate security since it mandates TLS1.3 
where early data opens the door to all sorts of nasties.  Here are my other 
comments.

pce-pcep-stateful-pce-gmpls I think is now RFC8779

s.4.1.1.1 just one List I see

s.6.1 the list is also keyed on lsp-id

The YANG module has lower case must/should; is this intended?

The timer names are not those of RFC5440 - perhaps worth a note giving the 
mapping even if it is only hyphen-minus

container SR
set to true if SR is enabled
Where is that enabled, for what scope?

likewise msd; other I-D decompose MSD three ways on a per signalling basis, I 
am not clear which MSD applies here.  A bit like MTU, it  might need a context 
to be clear.

The reference for path-key looks like it is a line too long

RFC8231 says srp-id  is reserved in which case the range should not be 
..max; this was correct in -18

I do not understand the use of must + error-message for config false.  I am 
used to it for validating an update and cannot see when this message will be 
generated.  This occurs in a number of places.

RPC often have a nacm default-deny-all

s.9 
The YANG modules   .../is/are/ 

Tom Petch


Thanks,

Julien



___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Last Call for draft-ietf-pce-pcep-yang-19

2022-10-03 Thread tom petch 
From: Pce  on behalf of julien.meu...@orange.com 

Sent: 26 September 2022 14:01

Hi PCE WG,

This message starts a 2-week WG Last Call for
draft-ietf-pce-pcep-yang-19. Please review and share any feedback using
the PCE mailing list.
This WGLC will end on Tuesday October 11.


There are several little problems with this I-D, which I will post in due 
course, but one big one that I think needs outside assistance and will take 
time to resolve, namely the lack of security.

This imports netconf-tls groupings and the netconf  I-D says basically security 
is nothing to do with us, that is up to the user of the grouping.  It 
recommends TLS1.3 and says TLS1.2 is obsolete and not recommended.

Trouble is, for most users TLS1.3 is not recommended because it is insecure 
because it introduces new features which are fine for web access and dangerous 
for almost other cases (eg early data).  There are a number of IETF documents 
looking at this and nailing down all the things you must not do with TLS1.3 in 
an operational environment (which is what most of the IETF is about).  RFC9190 
section 2 is an example of what I mean but from tracking the evolution of that 
RFC I suspect that that got watered down by the supporters of TLS1.3.

This I-D needs the equivalent (or else a MUST NOT for TLS1.3!).  Many of those 
involved with security in the IETF will not understand the issue, how dangerous 
TLS1.3 is for anything other than web access.

Tom Petch

Thanks,

Julien



___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] WG Last Call for draft-ietf-pce-pcep-yang-19

2022-09-26 Thread julien.meuric 

Hi PCE WG,

This message starts a 2-week WG Last Call for 
draft-ietf-pce-pcep-yang-19. Please review and share any feedback using 
the PCE mailing list.

This WGLC will end on Tuesday October 11.

Thanks,

Julien




smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce