Sheng Jiang <shengji...@bupt.edu.cn> wrote:
> I do not prefer the "all-covered" model. As you stated, all has to be
> "known" for now. What if another unknown requirement appeared？ Another
> bis, BRSKI v3? I think it is better that rfc8366bis covers an
> extensible generic framework and rules for future extensions. So, the
> future requirements and their mechanism can be developed independently
> without update BRSKI fundamental specification.
It would be better to make it extensible, but augment does not amend existing
modules, it extends them to make new modules.
If another requirement arrives, we have to do another revision.
That argues for making rfc8366bis not replace RFC8366, but just amend the
YANG module. These are questions I've been posting about for months now.
You'll see how the YANG is isolated in other submissions, such as:
draft-ietf-opsawg-service-assurance-architecture
draft-ietf-opsawg-service-assurance-yang
8366 doesn't have a lot of explanation actually, outside of the YANG module.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
