Hi Bo, Just a quick reminder that you can post a -15 (which I don’t think that I have seen), and then I can approve this.
Regards, Rob From: Wubo (lana) <lana.w...@huawei.com> Sent: 25 October 2022 08:26 To: Rob Wilton (rwilton) <rwil...@cisco.com>; draft-ietf-opsawg-yang-vpn-service-pm....@ietf.org Cc: adr...@olddog.co.uk; opsawg@ietf.org Subject: RE: New Version Notification - draft-ietf-opsawg-yang-vpn-service-pm-14.txt Hi Rob, Many thanks for your suggestion. We will submit R-15 to fix this when the I-D submission reopen. Thanks, Bo From: Rob Wilton (rwilton) [mailto:rwil...@cisco.com] Sent: Friday, October 21, 2022 6:06 PM To: Wubo (lana) <lana.w...@huawei.com<mailto:lana.w...@huawei.com>>; draft-ietf-opsawg-yang-vpn-service-pm....@ietf.org<mailto:draft-ietf-opsawg-yang-vpn-service-pm....@ietf.org> Cc: adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>; opsawg@ietf.org<mailto:opsawg@ietf.org> Subject: RE: New Version Notification - draft-ietf-opsawg-yang-vpn-service-pm-14.txt Hi Bo, I think that “limit-number” name makes more sense in the context of the other peer leaves around it when it is defined under “mac-addr-limit”, i.e., the “time-interval”, and what action is being taken. My “no hats” opinion is that I would still go for consistency with the other counters under entry-summary. E.g., using the same naming convention between the “maximum” and the “active”, and between v4, v6 and mac addresses. If it helps you could also make the relationship to mac-policies/limit-number clear as part of the description. But I’ll leave this entirely as the authors decision, this is just a minor non-blocking comment. Regards, Rob From: Wubo (lana) <lana.w...@huawei.com<mailto:lana.w...@huawei.com>> Sent: 21 October 2022 10:41 To: Rob Wilton (rwilton) <rwil...@cisco.com<mailto:rwil...@cisco.com>>; draft-ietf-opsawg-yang-vpn-service-pm....@ietf.org<mailto:draft-ietf-opsawg-yang-vpn-service-pm....@ietf.org> Cc: adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>; opsawg@ietf.org<mailto:opsawg@ietf.org> Subject: RE: New Version Notification - draft-ietf-opsawg-yang-vpn-service-pm-14.txt Hi Rob, Thanks for the review and suggestion. Per the naming of "mac-limit-number", we are considering to be consistent with L2NM definition: https://datatracker.ietf.org/doc/html/rfc9291: | +--rw mac-policies | | +--rw mac-addr-limit | | | +--rw limit-number? uint16 | | | +--rw time-interval? uint32 | | | +--rw action? Identityref Do you think this makes sense? Thanks, Bo -----Original Message----- From: Rob Wilton (rwilton) [mailto:rwil...@cisco.com] Sent: Friday, October 21, 2022 5:31 PM To: draft-ietf-opsawg-yang-vpn-service-pm....@ietf.org<mailto:draft-ietf-opsawg-yang-vpn-service-pm....@ietf.org> Cc: adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>; opsawg@ietf.org<mailto:opsawg@ietf.org> Subject: RE: New Version Notification - draft-ietf-opsawg-yang-vpn-service-pm-14.txt Hi authors, shepherd, Thanks for quickly posting a new version of draft-ietf-opsawg-yang-vpn-service-pm addressing the AD comments during the IESG review. The changes all look good to me, except that I question one of the changes that were made (in response to one of Eric's comments I think): augment /nw:networks/nw:network/nw:node: +--rw node-type? identityref +--ro entry-summary +--ro ipv4-num | +--ro maximum-routes? uint32 | +--ro total-active-routes? uint32 +--ro ipv6-num | +--ro maximum-routes? uint32 | +--ro total-active-routes? uint32 +--ro mac-num +--ro mac-limit-number? uint32 +--ro total-active-mac-num? uint32 mac-num-limit has been changed from mac-num-limit to max-limit-number, but I was wondering whether you considered trying to make the names for the mac entry limits more consistent with the names of the IP route limits. E.g., augment /nw:networks/nw:network/nw:node: +--rw node-type? identityref +--ro entry-summary +--ro ipv4-num | +--ro maximum-routes? uint32 | +--ro total-active-routes? uint32 +--ro ipv6-num | +--ro maximum-routes? uint32 | +--ro total-active-routes? uint32 +--ro mac-num +--ro maximum-mac-entries? uint32 +--ro total-active-mac-entries? uint32 This is a just a suggestion. Please let me know if you wish to make this change and post an updated draft, or whether you would like me to proceed with approving the -14 version. Regards, Rob > -----Original Message----- > From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> > <internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>> > Sent: 21 October 2022 09:37 > To: adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>; Rob Wilton (rwilton) > <rwil...@cisco.com<mailto:rwil...@cisco.com>> > Subject: New Version Notification - draft-ietf-opsawg-yang-vpn-service-pm- > 14.txt > > > A new version (-14) has been submitted for draft-ietf-opsawg-yang-vpn- > service-pm: > https://www.ietf.org/archive/id/draft-ietf-opsawg-yang-vpn-service-pm-14.txt > > Sub state has been changed to AD Followup from Revised ID Needed > > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-yang-vpn-service-pm/ > > Diff from previous version: > https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-14 > > IETF Secretariat. >
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg