Hi Med,
Thanks for addressing the comments.
I have one more observation: in Section 4.5. Conditional Statements, the
preferred and non-preferred do not seem to be semantically equivalent. The
following data instance is not allowed for the non-preferred example model,
but it is allowed for the preferred example model.
{
"type": "a",
"type-b": {
"foo": "foo-value"
}
Thanks,
- Xufeng
On Fri, Jun 21, 2024 at 1:57 PM <[email protected]> wrote:
> Hi Xufeng,
>
> FWIW, all the changes indicated in my reply are now implemented in
> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8407bis/12/.
>
> Thanks again for your careful review.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : BOUCADAIR Mohamed INNOV/NET
> > Envoyé : mardi 18 juin 2024 09:04
> > À : 'Xufeng Liu' <[email protected]>; yang-
> > [email protected]
> > Cc : [email protected]; last-
> > [email protected]; [email protected]
> > Objet : RE: Yangdoctors last call review of draft-ietf-netmod-
> > rfc8407bis-11
> >
> > Hi Xufeng,
> >
> > Thank you for the review.
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : Xufeng Liu via Datatracker <[email protected]> Envoyé :
> > mardi 18
> > > juin 2024 05:33 À : [email protected] Cc :
> > > [email protected]; last- [email protected];
> > > [email protected] Objet : Yangdoctors last call review of
> > > draft-ietf-netmod-
> > > rfc8407bis-11
> > >
> > >
> > > Reviewer: Xufeng Liu
> > > Review result: Ready with Nits
> > >
> > > 3.2. Code Components
> > > The “file name” after the "<CODE BEGINS>" tag is something
> > described
> > > as “SHOULD” be included. If there is no such a “file name”, the
> > tool
> > > “rfcstrip”
> > > will not extract the correct file. Should we consider making
> > this
> > > “file name” a “MUST”?
> >
> > [Med] I tend to agree with you on this one.
> >
> > >
> > > 3.5.1. YANG Module Classification
> > > In the section “Network model”, the term "Network model” is
> > described
> > > as “relevant protocols operating at the link and network
> > layers”. Can
> > > a network model be designed for other layers, such as OTN or
> > MPLS?
> >
> > [Med] Yes as far as it "describes a network-level abstraction (or
> > a subset of aspects of a network infrastructure)". Please note
> > that the text you quoted starts with "including", which does not
> > exclude other network-level matters.
> >
> >
> > If so, such a description seems to
> > > be too narrow. RFC 8309 clarifies the “Service Model”, which
> > is the
> > > section before this one. Is there a definition of the “network
> > model”
> > > in RFC 8309?
> >
> > [Med] No. However, this maps to "network configuration model"
> > mentioned in the example illustrated in Figure 3 of RFC8309. This
> > is mentioned in the text:
> >
> > This model corresponds to
> > the network configuration model discussed in [RFC8309].
> >
> > RFC8969 does not mention "configuration" because a network model
> > can be used for non-configuration purposes.
> >
> > >
> > > 3.8. IANA Considerations Section
> > > The “YANG Module Names” registry is defined in RFC 6020, but
> > not RFC
> > > 7950. Many YANG module writers mistakenly used RFC 7950.
> > > Should we consider bringing this up with special attention?
> >
> > [Med] We do already have the following:
> >
> > Section 3.8:
> > Each normative YANG module MUST be registered in both the
> > "IETF XML
> > Registry" [RFC3688] [IANA-XML] and the "YANG Module Names"
> > registry
> > [RFC6020] [IANA-MOD-NAMES].
> >
> > Appendix A:
> > * IANA Considerations section -- this section must always be
> > present. For each module within the document, ensure that
> > the
> > IANA Considerations section contains entries for the
> > following
> > IANA registries:
> >
> > XML Namespace Registry: Register the YANG module
> > namespace.
> >
> > YANG Module Registry: Register the YANG module name,
> > prefix,
> > namespace, and RFC number, according to the rules
> > specified in
> > [RFC6020].
> >
> > We might further emphasis on this point by adding a registration
> > template in Section 3.8. A PR to exercise this can be seen here:
> > https://github.com/netmod-wg/rfc8407bis/pull/56/files.
> >
> > >
> > > 4.5. Conditional Statements
> > > An example not preferred is given, but there is no preferred
> > fix.
> > > Would it be better to provide the proffered solution?
> > >
> >
> > [Med] Good point. Please see https://github.com/netmod-
> > wg/rfc8407bis/pull/57/files
>
>
> ____________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
