[Lsr] Re: Yangdoctors last call review of draft-ietf-lsr-ospf-admin-tags-16

[maqiufang (A)]

Thanks Yingzhen for taking care of my comments!
Just a reminder that please also update nodes/subtrees listed in the security 
consideration sec. to reflect your module update.

Best Regards,
Qiufang
From: Yingzhen Qu [mailto:yingzhen.i...@gmail.com]
Sent: Thursday, May 30, 2024 8:52 AM
To: maqiufang (A) 
Cc: yang-doct...@ietf.org; draft-ietf-lsr-ospf-admin-tags@ietf.org; 
last-c...@ietf.org; lsr@ietf.org
Subject: Re: Yangdoctors last call review of draft-ietf-lsr-ospf-admin-tags-16

Hi Qiufang,

Thanks for the review and sorry for the delayed response. I've uploaded version 
-18 to address your comments, details below.

Thanks,
Yingzhen

On Tue, Mar 12, 2024 at 5:29 AM Qiufang Ma via Datatracker 
mailto:nore...@ietf.org>> wrote:
Reviewer: Qiufang Ma
Review result: Almost Ready

Hi, this is my YANG Doctor review of draft-ietf-lsr-ospf-admin-tags-16, I
marked the review as “Almost Ready” with a couple of comments and questions
below.

(1) For the "ietf-ospf-admin-tags" YANG data model, what is the consideration
for the “advertise-prefixes” data node to be defined as a list with only one
child key inside it? Will this list node be populated with new parameters in
the future? Otherwise I think a simpler definition might be the following: OLD:
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area
/ospf:interfaces/ospf:interface:
  +--rw admin-tags
 +--rw tags* [tag]
+--rw tag   uint32
+--rw advertise-prefixes* [prefix]
   +--rw prefixinet:ip-prefix

NEW:
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area
/ospf:interfaces/ospf:interface:
  +--rw admin-tags
 +--rw tags* [tag]
+--rw tag   uint32
+--rw advertise-prefix* inet:ip-prefix

There is nothing wrong to be defined in the current draft (e.g., PYANG won’t
complain), but I think it can be hierarchically reduced this way, thoughts?
[Yingzhen]: we've modified the interface configuration. Please see whether it 
addressed your comments.

(2) For the grouping "prefix-admin-tag-sub-tlvs", it is defined and used to
augment the OSPF YANG data model and the OSPFv3 Extended LSA YANG data model.
There is a list defined inside the grouping definition, with only one child
declared as leaf-list. I am wondering why the type and length are not defined
inside admin-tag-sub-tlv list? Aren’t they part of the admin tag TLV?
[Yingzhen]: removed the list. As for the type and length, we're following the 
style as in
the base OSPF model (RFC 9129). When a tlv is known to an implementation, the 
type
and length is used to parse the tlv, so only the content is shown under the tlv 
container.
However for unknown TLVs, type and length are shown.

(3) The reference info inside the “revision” statement for this draft is
inconsistent with its real title. It is using “RFC : YANG Data Model for
OSPF Prefix Administrative Tags.”, while it should be “RFC : Extensions to
OSPF for Advertising Prefix Administrative Tags”.
[Yingzhen]: fixed.

(4) There are some list/leaf-list data nodes defined in the YANG data model
with their names defined as plural (e.g., tags, advertise-prefixes,
admin-tags), but the naming convention is to have the list/leaf-list name
singular form. See RFC8407bis
(https://www.ietf.org/archive/id/draft-ietf-netmod-rfc8407bis-09.html#section-4.3.1)
for the following: “List identifiers SHOULD be singular with the surrounding
container name plural. Similarly, "leaf-list" identifiers SHOULD be singular.”
[Yingzhen]: fixed.

(5) There is a YANG tree diagram included in the draft, an informative
reference to RFC 8340 should be added in the draft. See RFC8407bis
(https://www.ietf.org/archive/id/draft-ietf-netmod-rfc8407bis-09.html#section-3.4)
for the following: “If YANG tree diagrams are used, then an informative
reference to the YANG tree diagrams specification MUST be included in the
document. Refer to Section 2.2 of [RFC8349] for an example of such a reference.”
[Yingzhen]: fixed.

(6) It would be good if the tree structure of the YANG module could be defined
in a separate section/subsection, so that readers are able to navigate to the
overview (i.e., tree structure) of the model quickly if they want. Just a
suggestion for the authors to consider.
[Yingzhen]: split into sub sections now.

(7) Please include a note to the RFC editor requesting RFC  and (or
even better, use RFC  for draft-ietf-lsr-ospfv3-extended-lsa-yang) is
replaced with the RFC number that is assigned to the document.
[Yingzhen]:  draft-ietf-lsr-ospfv3-extended-lsa-yang is in Auth48 state, and 
will be published as RFC 9587. Once it's published, we'll update the draft 
accordingly.

(8) I see a couple of “TBD” throughout the draft, did the authors le

Re: [Lsr] WG Last Call for IGP extension for PCEP security capability support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05

[maqiufang (A)]

Hi, Ketan,

Thanks for your comments. Please see my reply inline.

发件人: Pce [mailto:pce-boun...@ietf.org] 代表 Ketan Talaulikar (ketant)
发送时间: 2021年7月23日 21:10
收件人: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org
抄送: 
draft-ietf-lsr-pce-discovery-security-supp...@ietf.org;
 p...@ietf.org
主题: Re: [Pce] WG Last Call for IGP extension for PCEP security capability 
support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05

Hello All,

I have reviewed this draft and have the following comments for the authors to 
address and the WG to consider:

1)  Is there any precedent for the advertisement of auth keychain info 
(ID/name) in such a manner that is flooded across the IGP domain? When the 
actual keychain anyway needs to be configured on all PCCs what is really the 
value in their advertisement other than possibly exposure to attack? I hope the 
security directorate reviewer looks at this closely and we get some early 
feedback specifically on this aspect.
[Qiufang Ma] See Acee’s response, thanks Acee.

2)  In sec 3.2 and 3.3, new sub-TLVs are being introduced. Their ASCII art 
pictures represent the OSPF TLVs. The ISIS TLV structure is different. While 
this will be obvious to most in this WG, I would request this to be clarified – 
perhaps by introducing separate diagrams for both protocols or skipping the art 
altogether.
[Qiufang Ma] Good catch, I prefer to skip the art altogether.

3)  RFC5088 applies to both OSPFv2 and OSPFv3. This is however not clear in 
the text of this document.
[Qiufang Ma] This draft is built on top of RFC 5088, therefore the extension 
defined in this draft is applied to both OSPFv2 and OSPFv3. I understand your 
confusion in the IANA and will fix this in the IANA.

4)  Looks like RFC5088 asked for the PCE Capabilities Flags registry to be 
created as a top-level IANA OSPF registry - 
https://datatracker.ietf.org/doc/html/rfc5088#section-7.2 – so it should have 
been placed here : 
https://www.iana.org/assignments/ospf-parameters/ospf-parameters.xhtml. What 
seems to have happened is that it got created under OSPFv2 which is wrong - 
https://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xml#ospfv2-parameters-14.
 Since this draft updates RFC5088, it is necessary for this document to fix 
this error. I would support Les in that perhaps all of this (i.e. everything 
under/related to PCED TLV) ought to be moved under the IANA Common IGP registry 
here : https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml
[Qiufang Ma] I tend to agree with you. but I am not sure how to move other 
existing created registry for Path Computation Element (PCE) Capability Flags 
available at
https://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xml#ospfv2-parameters-14
  to the new location you recommended.
https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml
I need to request the guidance from our chairs and AD for this.
5)  The document needs to be more specific and clear about which IANA 
registries to be used to avoid errors that have happened in the past (see (3) 
above).
[Qiufang Ma] Please see above.
6)  Appendix A, I believe what the authors intended here was that whether 
to use MD5 auth or not was part of discovery but static configuration on the 
PCE and PCC? The keychain introduced in this document can also be used along 
with MD5. Honestly, I don’t see a strong reason to not include MD5 in the 
signalling except that it is deprecated (even if widely deployed). This 
document would not conflict or contradict with RFC5440 if it did include a bit 
for MD5 support as well. As  follow-on, perhaps this document should also 
update RFC5440 – specifically for the security section? I see RFC8253 
introducing TLS that updates RFC5440 but nothing that introduces TCP-AO?. In 
any case, these are aspects for PCE WG so I will leave those to the experts 
there.
[Qiufang Ma] See Qin's reply to Acee. I hope your comment get addressed over 
there. My personally opinion is MD5 is weak and should be deprecated, thus it 
doesn't worth new protocol extension for TCP MD5 support.

Best Regards,
Qiufang Ma

Thanks,
Ketan

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: 21 July 2021 22:16
To: lsr@ietf.org
Cc: 
draft-ietf-lsr-pce-discovery-security-supp...@ietf.org
Subject: [Lsr] WG Last Call for IGP extension for PCEP security capability 
support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05

This begins a 3-week WG Last Call, ending on August 4th, 2021, for 
draft-ietf-lsr-pce-discovery-security-support. Please indicate your support or 
objection to this list before the end of the WG last call. The longer WG last 
call is to account for IETF 

Re: [Lsr] LSR WG Adoption Call for SRv6 YANG drafts

[maqiufang (A)]

Hi, all,
I support the adoption of these two drafts.
As a co-author of IS-IS SRv6 
draft(https://datatracker.ietf.org/doc/draft-hu-isis-srv6-yang/), I am not 
aware any IPR that applies to this draft.

Best Regards,
Qiufang Ma

-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
Sent: Thursday, July 22, 2021 6:48 PM
To: lsr@ietf.org
Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org
Subject: [Lsr] LSR WG Adoption Call for SRv6 YANG drafts


Hi Folks,

This begins a 3 week WG Adoption Call for the following related YANG drafts:

https://datatracker.ietf.org/doc/draft-hu-isis-srv6-yang/
https://datatracker.ietf.org/doc/draft-hu-lsr-ospf-srv6-yang/

Please indicate your support or objections by August 12th, 2021

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to these drafts.

Thanks,
Chris.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call IPR Poll for IGP extension for PCEP security capability support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05

[maqiufang (A)]

Hi, Acee,

I am not aware of any other IPR that applies to this draft.

Best Regards,
Qiufang Ma

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Thursday, July 22, 2021 12:37 AM
To: draft-ietf-lsr-pce-discovery-security-supp...@ietf.org
Cc: lsr@ietf.org
Subject: WG Last Call IPR Poll for IGP extension for PCEP security capability 
support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05

The following IPR has been filed for 
draft-ietf-lsr-pce-discovery-security-support:

https://datatracker.ietf.org/ipr/3351/

Are you aware of any other IPR that applies to 
draft-ietf-lsr-pce-discovery-security-support?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks,
Acee



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-ietf-lsr-pce-discovery-security-support-04.txt

[maqiufang (A)]

Hi, all:
 We have updated the draft: 
https://www.ietf.org/archive/id/draft-ietf-lsr-pce-discovery-security-support-04.txt
The diff is available at: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-pce-discovery-security-support-04

Your comments would be greatly appreciated.


Qiufang Ma(on behalf of authors)

-邮件原件-
发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
发送时间: 2020年10月21日 19:46
收件人: Diego R. Lopez ; Qin Wu 
; Qin Wu ; Diego Lopez 
; Dhruv Dhody ; Daniel King 
; maqiufang (A) 
主题: New Version Notification for 
draft-ietf-lsr-pce-discovery-security-support-04.txt


A new version of I-D, draft-ietf-lsr-pce-discovery-security-support-04.txt
has been successfully submitted by Qin Wu and posted to the IETF repository.

Name:   draft-ietf-lsr-pce-discovery-security-support
Revision:   04
Title:  IGP extension for PCEP security capability support in the PCE 
discovery
Document date:  2020-10-21
Group:  lsr
Pages:  10
URL:
https://www.ietf.org/archive/id/draft-ietf-lsr-pce-discovery-security-support-04.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-pce-discovery-security-support
Htmlized:   
https://tools.ietf.org/html/draft-ietf-lsr-pce-discovery-security-support-04
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-pce-discovery-security-support-04

Abstract:
   When a Path Computation Element (PCE) is a Label Switching Router
   (LSR) participating in the Interior Gateway Protocol (IGP), or even a
   server participating in IGP, its presence and path computation
   capabilities can be advertised using IGP flooding.  The IGP
   extensions for PCE discovery (RFC 5088 and RFC 5089) define a method
   to advertise path computation capabilities using IGP flooding for
   OSPF and IS-IS respectively.  However these specifications lack a
   method to advertise PCEP security (e.g., Transport Layer
   Security(TLS), TCP Authentication Option (TCP-AO)) support
   capability.

   This document proposes new capability flag bits for PCE-CAP-FLAGS
   sub-TLV that can be announced as attribute in the IGP advertisement
   to distribute PCEP security support information.  In addition, this
   document updates RFC 5088 and RFC 5089 to allow advertisement of Key
   ID or Key Chain Name Sub-TLV to support TCP AO security capability.


  


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr