Since the ipv4-address-no-zone type is derived from the ipv4-address
type and the ipv4-address type has the detailed pattern, there is no
need to repeat the details. An ipv4-address value has to satisfy both
the ipv4-address-no-zone pattern and the ipv4-address pattern.

I believe this errata should be rejected.

/js

On Fri, Jul 29, 2022 at 10:32:27AM -0700, RFC Errata System wrote:
> The following errata report has been submitted for RFC6991,
> "Common YANG Data Types".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7062
> 
> --------------------------------------
> Type: Technical
> Reported by: Mazhar Rana <[email protected]>
> 
> Section: 4
> 
> Original Text
> -------------
>      typedef ipv4-address-no-zone {
>        type inet:ipv4-address {
>          pattern '[0-9\.]*';
>        }
>        description
>          "An IPv4 address without a zone index.  This type, derived from
>           ipv4-address, may be used in situations where the zone is
>           known from the context and hence no zone index is needed.";
>      }
> 
> Corrected Text
> --------------
>      typedef ipv4-address-no-zone {
>        type inet:ipv4-address {
>          pattern '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
>          +  '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])';
>        }
>        description
>          "An IPv4 address without a zone index.  This type, derived from
>           ipv4-address, may be used in situations where the zone is
>           known from the context and hence no zone index is needed.";
>      }
> 
> Notes
> -----
> As per RFC 4001, dotted decimal format of IPv4 address is typically written 
> in decimal digits, formatted as four 8-bit fields that are separated by 
> periods.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC6991 (draft-ietf-netmod-rfc6021-bis-03)
> --------------------------------------
> Title               : Common YANG Data Types
> Publication Date    : July 2013
> Author(s)           : J. Schoenwaelder, Ed.
> Category            : PROPOSED STANDARD
> Source              : Network Modeling
> Area                : Operations and Management
> Stream              : IETF
> Verifying Party     : IESG

-- 
Jürgen Schönwälder              Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to