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
