[Last-Call] Re: Yangdoctors last call review of draft-ietf-netmod-rfc8407bis-11

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Xufeng, 

Thank you for the review.

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Xufeng Liu via Datatracker <noreply@xxxxxxxx>
> Envoyé : mardi 18 juin 2024 05:33
> À : yang-doctors@xxxxxxxx
> Cc : draft-ietf-netmod-rfc8407bis.all@xxxxxxxx; last-
> call@xxxxxxxx; netmod@xxxxxxxx
> 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.
-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux