HI Roman,

I will let Med respond to your questions, but here is my understanding of some 
of your questions.

> On Mar 31, 2025, at 6:49 AM, Roman Danyliw via Datatracker <[email protected]> 
> wrote:
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-netmod-acl-extensions-15: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to 
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-extensions/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> The XSLT of Appendix A.1, A.2 and A.3 imports “iana-yinx.xsl”:
> 
>     <import href="../../../xslt/iana-yinx.xsl"/>
> 
> Where does this file come from?  The XSLT does not compile without it.
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you to Russ Housley for the GENART review.
> 
> ** Section 6.3.1
>   "enum":  Replicates the name from the registry with all spaces
>      striped.
> 
> How should the text in the parentheses be handled (e.g., “Information Request
> (Deprecated)”)?

The text in the parenthesis is the current status of the type, and is not part 
of the name. As such, in the YANG module, the definition would come out, again 
taking your example, as:

      enum InformationRequest {
        value 15;
        status deprecated;
        description
          "Information Request (Deprecated)";
        reference
          "- RFC 792
           - RFC 6918";
      }
  
where the name of the enum does not carry what is in the parenthesis. statement 
“status deprecated” is derived from what is the parenthesis, and the 
description statement essentially copies the field from the IANA registry.

> 
> Appendix A.2 seems to indicate that the content in the parenthesis should be
> stripped.  Perhaps additional text could be added here that this column is
> formatted according to the XSLT in Appendix A.1.

Stripped from the name, yes. 

> 
> This feedback applies to Sections 6.3.2 and 6.3.3 too.
> 
> ** Section 6.3.1
>   "status":  Is included only if a registration has been deprecated or
>      obsoleted.  IANA "deprecated" maps to YANG status "deprecated",
>      and IANA "obsolete" maps to YANG status "obsolete".
> ...
>   IANA is requested to add this note to "ICMP Type Numbers"
>   [IANA-ICMPv4]:
> ...
> 
> [IANA-ICMPv4]
>              "ICMP Type Numbers", n.d.,
>              <https://www.iana.org/assignments/icmp-parameters/icmp-
>              parameters.xhtml>.
> 
> -- This reference should be normative since it is part of the IANA guidance
> 
> -- Shouldn’t the link to “ICMP Type Numbers” be
> https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml#icmp-parameters-types
> 
> -- How does one know an entry is “obsolete” or “deprecated”?  Is it by looking
> for those strings in the name field?   There are a few that are “deprecated”
> but not “obsolete”
> 
> The same feedback applies to Section 6.3.2 and 6.3.3?

It is derived from what is in the parenthesis. The status can either be 
‘deprecated’ or ‘obsolete’ but not both.

Thanks.

> 
> 
> 


Mahesh Jethanandani
[email protected]






_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to