Hi WG,

I support adoption. Just a few thoughts...

- This document has "Updates: 8782" in its header. Surely a mistake!
- This text

   To avoid the issues discussed above, this document defines a common
   YANG module that is meant to be reused by various VPN-related modules
   such as Layer 3 VPN Service Model (L3SM) [RFC8299], Layer 2 VPN
   Service Model (L2SM) [RFC8466], Layer 3 VPN Network Model (L3NM)
   [I-D.ietf-opsawg-l3sm-l3nm], and Layer 2 VPN Network Model (L2NM)
   [I-D.ietf-opsawg-l2nm]: "ietf-vpn-common" (Section 4).

While it is clear how this common model can be used by
work-in-progress L3NM and L2NM models, I am not sure about the
published service model. Maybe you want to suggest that a future
update of these service models MAY use this common model? If yes,
better to be explicit.

- I was hoping to find L3NM and L2NM models using this common model
either in the draft or Github. Maybe the plan to update only after
successful adoption by the WG?

Thanks!
Dhruv

On Thu, Aug 13, 2020 at 6:19 PM Joe Clarke (jclarke)
<[email protected]> wrote:
>
> Hello, WG members.  On the IETF 108 virtual meeting, Oscar presented the 
> status of the L3NM, L2NM, and the VPN common work.  While this VPN common 
> YANG module started as an individual document (per the chairs’ request), the 
> L2NM and L3NM modules need to choose a direction for how to handle common 
> typedefs and groupings between them.
>
> On the virtual meeting we did a hum which indicated “Pianissimo” support.  
> Again, the hum system had some interesting rules, so this is not conclusive, 
> but seems to favor that this common module work should exist as its own, 
> standalone document that both L2NM and L3NM will consume.  In this manner, 
> one would not need to import either L2NM or L3NM to make use of/extend these 
> common attributes.
>
> To that end, the chairs would like a call for adoption of 
> draft-bgbw-opsawg-vpn-common.  Additionally, comments on the approach and the 
> choice of common attributes are welcome, especially from those that were 
> unable to attend the IETF 108 virtual meeting.
>
> This serves as a two week call for adoption ending on August 27, 2020.
>
> Thanks.
>
> Joe
> _______________________________________________
> OPSAWG mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/opsawg

_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to