Dean,
Thanks.
As this is part of the early YANG doctor process, let me copy the YANG
doctors, WG chairs, and ADs (as described at
https://www.ietf.org/iesg/directorate/yang-doctors.html)
Regards, Benoit
Authors,
I don’t have deep knowledge of PIM, so if some protocol specifics
haven’t been modeled right, I missed them. For application comparison,
was looking at Juniper PIM configuration. The modules are using
draft-ietf-netmod-routing-cfg as base, and follows the
routing-instance-centric model, hence didn’t have problems mapping it
to Junos PIM config style. The model design by using base module and
build for each specific variant a separate module is a good approach,
as it enables simpler application of the modules by vendors and users.
Throughout the draft authors are using abbreviations (many of them not
widely known) and the terminology section is not complete for PIM. It
would be good to write them out when first time used in the text
example,
the configuration for PIM-SM that is not relevant for an SSM-only
implementation is collected in an ASM container.
Same thing is in the YANG module descriptions
enum new-dr {
description
"A new DR was elected on the connected network.";
}
enum new-df {
description
"A new DF was elected on the connected network.";
}
DR and DF should be spelled out in the description
Make the descriptions in the code consistent, like in following example
typedef pim-mode {
type enumeration {
enum none {
description
"PIM is not operating.";
}
enum ssm {
description
"Source-Specific Multicast (SSM) with PIM Sparse Mode.";
}
enum asm {
description
"Any Source Multicast (ASM) with PIM Sparse Mode.";
}
Why are the PIM related RFC not listed in the introduction section, as
there are clearly relations between the model and PIM related RFCs
In chapter 2.2, why are you stating vendors will augment with required
restrictions, but features might be added
It is expected that vendors
will augment the model with any specific restrictions that might be
required. Vendors may also extend the features list with proprietary
extensions.
It is expected that vendors will augment the model with any specific
extensions and restrictions needed to adapt it to their vendor
specific implementation.
In chapter 3.1 bullet 2, the chapter finishes with statement
which does not make sense for PIM.
It would be nice to explain why does it not make sense for PIM. Why is
there only 1 instances of PIM per VRF
From YANG perspective, the authors followed recommendations in the
draft-ietf-netmod-rfc6087-bis-08
Hope this helps
Dean
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
