subject:"\[OPSAWG\] New Version Notification \- draft\-ietf\-opsawg\-yang\-vpn\-service\-pm\-14.txt"

Re: [OPSAWG] New Version Notification - draft-ietf-opsawg-yang-vpn-service-pm-14.txt

2022-11-11 Thread Rob Wilton (rwilton)

Hi Bo,

Thanks, and no worries.

Document has been approved.  I would like to thank the authors, WG, and doc 
shepherd for their work on this draft.

Regards,
Rob


From: Wubo (lana) 
Sent: 11 November 2022 11:00
To: Rob Wilton (rwilton) ; 
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,

Sorry for the delay. Here is the update：
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-15

Thanks,
Bo

发件人: Rob Wilton (rwilton) mailto:rwil...@cisco.com>>
发送时间: 2022年11月11日 10:37
收件人: Wubo (lana) mailto:lana.w...@huawei.com>>; 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org
抄送: adr...@olddog.co.uk; 
opsawg@ietf.org
主题: RE: New Version Notification - draft-ietf-opsawg-yang-vpn-service-pm-14.txt

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) mailto:lana.w...@huawei.com>>
Sent: 25 October 2022 08:26
To: Rob Wilton (rwilton) mailto: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) mailto:lana.w...@huawei.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 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) mailto:lana.w...@huawei.com>>
Sent: 21 October 2022 10:41
To: Rob Wilton (rwilton) mailto: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,



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
Cc: adr...@olddog.co.uk; 
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,

Re: [OPSAWG] New Version Notification - draft-ietf-opsawg-yang-vpn-service-pm-14.txt

2022-11-11 Thread Wubo (lana)

Hi Rob,

Sorry for the delay. Here is the update：
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-15

Thanks,
Bo

发件人: Rob Wilton (rwilton) 
发送时间: 2022年11月11日 10:37
收件人: Wubo (lana) ; 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org
抄送: adr...@olddog.co.uk; opsawg@ietf.org
主题: RE: New Version Notification - draft-ietf-opsawg-yang-vpn-service-pm-14.txt

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) mailto:lana.w...@huawei.com>>
Sent: 25 October 2022 08:26
To: Rob Wilton (rwilton) mailto: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) mailto:lana.w...@huawei.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 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) mailto:lana.w...@huawei.com>>
Sent: 21 October 2022 10:41
To: Rob Wilton (rwilton) mailto: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,



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
Cc: adr...@olddog.co.uk; 
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

Re: [OPSAWG] New Version Notification - draft-ietf-opsawg-yang-vpn-service-pm-14.txt

2022-11-11 Thread Rob Wilton (rwilton)

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) 
Sent: 25 October 2022 08:26
To: Rob Wilton (rwilton) ; 
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) mailto:lana.w...@huawei.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 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) mailto:lana.w...@huawei.com>>
Sent: 21 October 2022 10:41
To: Rob Wilton (rwilton) mailto: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,



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
Cc: adr...@olddog.co.uk; 
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>>

> Sent: 21 October 2022 09:37

> To: adr...@olddog.co.uk; Rob Wilton (rwilton) 
> mailto:rwil...@cisco.com>>

> Subject:

Re: [OPSAWG] New Version Notification - draft-ietf-opsawg-yang-vpn-service-pm-14.txt

2022-10-25 Thread Wubo (lana)

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) ; 
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 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) mailto:lana.w...@huawei.com>>
Sent: 21 October 2022 10:41
To: Rob Wilton (rwilton) mailto: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,



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
Cc: adr...@olddog.co.uk; 
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>>

> Sent: 21 October 2022 09:37

> To: adr...@olddog.co.uk; Rob Wilton (rwilton) 
> 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:

>

Re: [OPSAWG] New Version Notification - draft-ietf-opsawg-yang-vpn-service-pm-14.txt

2022-10-21 Thread Rob Wilton (rwilton)

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) 
Sent: 21 October 2022 10:41
To: Rob Wilton (rwilton) ; 
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,



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
Cc: adr...@olddog.co.uk; 
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>>

> Sent: 21 October 2022 09:37

> To: adr...@olddog.co.uk; Rob Wilton (rwilton) 
> 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

Re: [OPSAWG] New Version Notification - draft-ietf-opsawg-yang-vpn-service-pm-14.txt

2022-10-21 Thread Wubo (lana)

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
Cc: adr...@olddog.co.uk; 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>>

> Sent: 21 October 2022 09:37

> To: adr...@olddog.co.uk; Rob Wilton (rwilton) 
> 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

Re: [OPSAWG] New Version Notification - draft-ietf-opsawg-yang-vpn-service-pm-14.txt

2022-10-21 Thread Rob Wilton (rwilton)

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 
> Sent: 21 October 2022 09:37
> To: adr...@olddog.co.uk; Rob Wilton (rwilton) 
> 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

Re: [OPSAWG] New Version Notification - draft-ietf-opsawg-yang-vpn-service-pm-14.txt

Re: [OPSAWG] New Version Notification - draft-ietf-opsawg-yang-vpn-service-pm-14.txt

Re: [OPSAWG] New Version Notification - draft-ietf-opsawg-yang-vpn-service-pm-14.txt

Re: [OPSAWG] New Version Notification - draft-ietf-opsawg-yang-vpn-service-pm-14.txt

Re: [OPSAWG] New Version Notification - draft-ietf-opsawg-yang-vpn-service-pm-14.txt

Re: [OPSAWG] New Version Notification - draft-ietf-opsawg-yang-vpn-service-pm-14.txt

Re: [OPSAWG] New Version Notification - draft-ietf-opsawg-yang-vpn-service-pm-14.txt

7 matches

Site Navigation

Mail list logo

Footer information