Skip to main content

YANG Data Model for L3VPN Service Delivery
RFC 8049

Yes

(Benoît Claise)
(Joel Jaeggli)

No Objection

(Deborah Brungard)
(Jari Arkko)
(Spencer Dawkins)

Note: This ballot was opened for revision 17 and is now closed.

Alvaro Retana No Objection

Comment (2016-10-25 for -18)

(Benoît Claise; former steering group member) Yes

Yes (for -17)

                            

(Joel Jaeggli; former steering group member) Yes

Yes (for -18)

                            

(Alexey Melnikov; former steering group member) No Objection

No Objection (2016-10-25 for -18)
This is generally a well written document, so only a couple of nits:

leaf country-code {
        type string;
        description
         "Country of the site.";
       }

2 letter country codes? 3 letted country codes? Please add a normative reference. (I think you meant 2-letter ISO country codes.)

14.2.  Informative References

   [I-D.ietf-netconf-restconf]
              Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", draft-ietf-netconf-restconf-17 (work in
              progress), September 2016.

This should be Normative due to RFC 2119 language used when mentioning RESTCONF. However it doesn't look like RESTCONF needs any normative language when mentioned. For example:

The configuration of network elements MAY be done by CLI,
   or by NETCONF ([RFC6241])/RESTCONF ([I-D.ietf-netconf-restconf])
   coupled with specific configuration YANG data models (BGP, VRF, BFD
   ...) or any other way.

I don't think use of MAY is correct here, because it is not an implementation choice that affects use of your document. I would just change "MAY" to "can".

There is another similar use later in the document.

(Alia Atlas; former steering group member) No Objection

No Objection (2016-10-26 for -18)
First, thank you very much for a well-written and easy to read and understand document.
There are a few places where expanding acronyms would be useful - but the RFC Editor can deal with those.

Nit:  Top of page 42 - sentence fragment 
"  Each constraint is expressed as "I want my current site-network-
   access to be <constraint-type> (e.g. pe-diverse, pop-diverse) from
   these <target> site-network-accesses".  In addition,
"
Model described as proposed - less tentative language for a standard is appropriate now.

(Alissa Cooper; former steering group member) No Objection

No Objection (2016-10-25 for -18)
Would suggest s/zip code/postal code/ since zip code is a US-only concept.

(Ben Campbell; former steering group member) No Objection

No Objection (2016-10-25 for -18)
This is a nicely readable document, especially given its size. I just have a few minor comments:

- There are a number of uses of MAY that seem more like statements of fact than permission to do something. Some of these take the form of "MAY decide" or "MAY want" that might be more appropriate if reformulated along the lines of "MAY do":
-- 5.6.3, last paragraph: "Other parameters like the requested svc-input-bandwidth, svc-output-
   bandwidth MAY help to decide the access type to be used."
-- 5.6.7, last paragraph: "Note that a service provider MAY decide..."
-- 5.11.6, last paragraph: "...user MAY decide..."
-- 5.13.1, first paragraph: "...a customer MAY want to..."
-- 7, 2nd paragraph: "The management system MAY be modular..." and "... the component...MAY be different."

- 14.2: As currently used, I think the references to restconf and to RFC6536 should be normative.

(Deborah Brungard; former steering group member) No Objection

No Objection (for -18)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (for -18)

                            

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2016-10-24 for -17)
Thanks for addressing the SecDir review:
https://www.ietf.org/mail-archive/web/secdir/current/msg06909.html

I'm sure the RFC editor would catch this, but IPsec instances should be replaced:
s/IPSec/IPsec/

(Mirja Kühlewind; former steering group member) No Objection

No Objection (2016-10-26 for -18)
Please spell out acronyms, e.g. OSS, CLI,ASM, SSM, RP, DHCP, OAM , BFD, LIME, VRF and many more... That would at least help me a lot :-)

Two question mainly on the transport constraints part (sec 5.13.2):

1) I don't really understand why there is bandwidth as a service parameter (section 5.12.1) and a transport constraint on bandwidth. Isn't that the same? Can you explain!

2) There is a transport constraint on path-diversity. Shouldn't that be a side specific parameter because that information in needed when placement is considered? And respectively isn't side-diversity already covered by Site network accesses parameters (sec 5.3.2)?

(Spencer Dawkins; former steering group member) No Objection

No Objection (for -18)

                            

(Stephen Farrell; former steering group member) (was Discuss) No Objection

No Objection (2016-10-26 for -18)
- 5.9.1: Just curious, the text says "   The current model
does not support any authentication parameters..." is that
because there's no user or host authentication?

- 5.9.2: I wondered why the empty "pki" container? Would it
not have been useul to define what's needed there, or do
you just never see IPsec using IKE for these VPNs? (Which
would be a bit sad;-)

(Suresh Krishnan; former steering group member) (was Discuss) No Objection

No Objection (2016-10-27 for -18)
Thanks for addressing my DISCUSS point by adding a new address allocation type (dhcp-slaac).