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

Hi Tom,

Thanks for your detailed review!

On Thu, Oct 6, 2022 at 5:13 PM tom petch <ietfc@btconnect.com> wrote:

> From: Pce <pce-bounces@ietf.org> on behalf of julien.meuric@orange.com <
> julien.meuric@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.
>
> <tp>
> 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 ffffffff 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
<https://www.rfc-editor.org/rfc/rfc7950.html#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
>