Re: [netmod] IPR Poll on draft-ietf-netmod-node-tags-06

[liupeng...@chinamobile.com]

Hi, all

"No, I'm not aware of any IPR that applies to this draft"

Regards
Peng Liu



liupeng...@chinamobile.com
 
From: Du Zongpeng
Date: 2022-04-10 09:49
To: 'Benoit Claise'; 'Kent Watsen'; 'Qin Wu'; 'Peng Liu'; 'Mohamed Boucadair'
CC: 'Liang Geng'; netmod@ietf.org
Subject: RE: IPR Poll on draft-ietf-netmod-node-tags-06
Hi, all
 
"No, I'm not aware of any IPR that applies to this draft"
 
Best Regards
Zongpeng Du
 
-邮件原件-
发件人: Benoit Claise [mailto:benoit.cla...@huawei.com] 
发送时间: 2022年4月9日 21:41
收件人: Kent Watsen; Qin Wu; Peng Liu; Zongpeng Du; Mohamed Boucadair
抄送: Liang Geng; netmod@ietf.org
主题: Re: IPR Poll on draft-ietf-netmod-node-tags-06
 
"No, I'm not aware of any IPR that applies to this draft"
 
Regards, Benoit
 
 
 
On 4/8/2022 8:09 PM, Kent Watsen wrote:
> [ Note: existing IPR declaration: https://datatracker.ietf.org/ipr/4216 ]
>
>
> Authors, Contributors, WG,
>
> As part of WG Last Call:
>
> Are you aware of any IPR that applies to drafts identified above?
>
> Please state either:
>
> "No, I'm not aware of any IPR that applies to this draft"
> or
> "Yes, I'm aware of IPR that applies to this draft"
>
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3669, 5378 and 8179 for more details)?
>
> If yes to the above, please state either:
>
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
> "No, the IPR has not been disclosed"
>
> If you answer no, please provide any additional details you think
> appropriate. If you are listed as a document author or contributor
> please answer the above by responding to this email regardless
> of whether or not you are aware of any relevant IPR. This
> document will not advance to the next stage until a response
> has been received from each author.
>
> NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.
>
> If you are on the WG email list or attend WG meetings but are not
> listed as an author or contributor, we remind you of your obligations
> under the IETF IPR rules which encourages you to notify the IETF
> if you are aware of IPR of others on an IETF contribution, or to
> refrain from participating in any contribution or discussion related
> to your undisclosed IPR. For more information, please see the RFCs
> listed above and
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
>
> Thank you,
> Kent (Co-Chair)
>
> PS Please include all listed in the headers of this message in your
> response.
>
>
> .
 
 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Andy Bierman]

On Sat, Apr 9, 2022 at 11:00 AM Acee Lindem (acee)  wrote:

> Hi Andy,
>
>
>
> My opinion remains the same that RFC 4001 got it right with types
> including the zone specification being the exception rather than the
> default. I know that when people think IP address, they think the dotted 4
> octet without “%” appended. I’d still like to know if there are
> products that actually make use of the zone?
>
>
>

I agree the YANG types should have been named differently,
but it was not flagged as a problem 12 years ago..


> See inline responses in the unsnipped email below.
>
>
>
> *From: *netmod  on behalf of Andy Bierman <
> a...@yumaworks.com>
> *Date: *Saturday, April 9, 2022 at 1:38 PM
> *To: *Randy Presuhn 
> *Cc: *"l...@ietf.org" , "netmod@ietf.org" 
> *Subject: *Re: [netmod] [Lsr] I-D Action:
> draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
>
>
>
>
>
>
>
> On Sat, Apr 9, 2022 at 9:51 AM Randy Presuhn <
> randy_pres...@alumni.stanford.edu> wrote:
>
> Hi -
>
> On 2022-04-09 4:36 AM, Christian Hopps wrote:
> ...
> > FWIW, I'm not arguing for this change; however, to be fair, isn't this
> > also about the existing published modules that are using the incorrect
> > type?
>
> No.  "Incorrect type" is a bit of a mischaracterization.  It's like
> saying using "int32" is incorrect if all that is needed is "uint16".
> One might say its a little sloppy or mutter "RTFM" under one's breath,
> but it's not "incorrect."
>
>
>
> You and Martin convinced me the ip-address type cannot be changed.
>
> There are other options.
>
>
>
> If a YANG module is using ip-address, and the WG intent was really to
>
> use ip-address-no-zone, then that module can be fixed with an Errata.
>
> The modules should not need to be updated just for this incorrect typedef
> usage.
>
>
>
> The type names are unfortunate but in the future this will not happen
> again.
>
>
>
> Well, these are probably some of the most ubiquitous types in the YANG and
> forcing everyone to use the -no-zone types is more a tragedy than merely
> unfortunate.
>

It must not be a real problem or it would not have taken 12 years to
surface.
The typedef is silent about ignoring an explicit zone index in an
ipv4-address value.
If that is allowed, then maybe existing modules do not need to change.
IMO they do not need to change anyway, since a server can just reject an
address with a zone index in it.

I don't think the YANG author or reader is that burdened if '-no-zone' is
added to the type name.



>
>
>
>
>
> Some modules have used a type that potentially can represent more
> values than are needed for the intended purpose.  Whether those
> implementations will ever accept or produce those values will
> depend on whether the code, whether library, generated, or hand-
> crafted, enforces the tighter constraints appropriate to the usage
> or only the looser constraints appropriate to the type's specification.
>
> But this is also true of every usage of any type where the use
> can only exhibit a subset of the possible values of the type,
> whether that subsetting is obvious from the description or not,
> so I find it really hard to get excited about it.  The more nuanced
> a repertoire of types becomes, the more likely developers won't
> use exactly the right one, though one would hope that these foibles
> are caught during the review process, at least until developers
> start reading the documentation for the libraries they employ.
>
>
>
> There are many examples where the pattern allows more strings
>
> than the intended usage.  Also, a server can reject any request for any
> reason.
>
>
>
> That does not address the conformance problem that Acee may be concerned
> about.
>
> What is a server required to support for a leaf with type ip-address?
>
> The text does not look like the zone index is optional for the server to
> accept.
>
>
>
>
>
> Even in these cases of "incorrect" usage, as Andy and others
> have pointed out, stuff still works, because those cases only
> require a subset of the values supported by the type.  If the
> proposed change is made, usages requiring the full value space of
> the original type definition will break, and those formerly
> "incorrect" usages will exhibit no change in their behavior.
>
>
>
>
>
> It works because clients are not sending addresses with a zone index.
>
> I agree with Martin that the NC/RC server is always obligated to reject a
> request
>
> it cannot fulfill, regardless of the typedef.
>
>
>
> I thought Martin said a server not supporting zone could accept the IP
> address and simply ignore the zone? This would seem to be a better options
> than using the -no-zone types.
>


Maybe. There is no text in the typedefs but descriptions in the leaf or
other
data node could specify this behavior, or it could be an implementation
decision.




>
>
>
> That is, the proposed change does not improve operation of
> anything, and it breaks some things.
>
>
>
> yes -- too many years out in the wild this way to switch type names 

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Acee Lindem (acee)]

Hi Andy,

My opinion remains the same that RFC 4001 got it right with types including the 
zone specification being the exception rather than the default. I know that 
when people think IP address, they think the dotted 4 octet without “%” 
appended. I’d still like to know if there are products that actually make use 
of the zone?

See inline responses in the unsnipped email below.

From: netmod  on behalf of Andy Bierman 

Date: Saturday, April 9, 2022 at 1:38 PM
To: Randy Presuhn 
Cc: "l...@ietf.org" , "netmod@ietf.org" 
Subject: Re: [netmod] [Lsr] I-D Action: 
draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt



On Sat, Apr 9, 2022 at 9:51 AM Randy Presuhn 
mailto:randy_pres...@alumni.stanford.edu>> 
wrote:
Hi -

On 2022-04-09 4:36 AM, Christian Hopps wrote:
...
> FWIW, I'm not arguing for this change; however, to be fair, isn't this
> also about the existing published modules that are using the incorrect
> type?

No.  "Incorrect type" is a bit of a mischaracterization.  It's like
saying using "int32" is incorrect if all that is needed is "uint16".
One might say its a little sloppy or mutter "RTFM" under one's breath,
but it's not "incorrect."

You and Martin convinced me the ip-address type cannot be changed.
There are other options.

If a YANG module is using ip-address, and the WG intent was really to
use ip-address-no-zone, then that module can be fixed with an Errata.
The modules should not need to be updated just for this incorrect typedef usage.

The type names are unfortunate but in the future this will not happen again.

Well, these are probably some of the most ubiquitous types in the YANG and 
forcing everyone to use the -no-zone types is more a tragedy than merely 
unfortunate.



Some modules have used a type that potentially can represent more
values than are needed for the intended purpose.  Whether those
implementations will ever accept or produce those values will
depend on whether the code, whether library, generated, or hand-
crafted, enforces the tighter constraints appropriate to the usage
or only the looser constraints appropriate to the type's specification.

But this is also true of every usage of any type where the use
can only exhibit a subset of the possible values of the type,
whether that subsetting is obvious from the description or not,
so I find it really hard to get excited about it.  The more nuanced
a repertoire of types becomes, the more likely developers won't
use exactly the right one, though one would hope that these foibles
are caught during the review process, at least until developers
start reading the documentation for the libraries they employ.

There are many examples where the pattern allows more strings
than the intended usage.  Also, a server can reject any request for any reason.

That does not address the conformance problem that Acee may be concerned about.
What is a server required to support for a leaf with type ip-address?
The text does not look like the zone index is optional for the server to accept.


Even in these cases of "incorrect" usage, as Andy and others
have pointed out, stuff still works, because those cases only
require a subset of the values supported by the type.  If the
proposed change is made, usages requiring the full value space of
the original type definition will break, and those formerly
"incorrect" usages will exhibit no change in their behavior.


It works because clients are not sending addresses with a zone index.
I agree with Martin that the NC/RC server is always obligated to reject a 
request
it cannot fulfill, regardless of the typedef.

I thought Martin said a server not supporting zone could accept the IP address 
and simply ignore the zone? This would seem to be a better options than using 
the -no-zone types.


That is, the proposed change does not improve operation of
anything, and it breaks some things.

yes -- too many years out in the wild this way to switch type names around now.

I know I may be being too pragmatic, but does anyone support zone via %?

Thanks,
Acee


For me, it's more important for stuff to work (and to not break
stuff) than it is to align perfectly with the underlying aesthetics
of some naming system attributed post hoc to a set of types.

Randy

Andy


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Acee Lindem (acee)]

I hate when people selectively snip my Emails and respond out of context. 
Please don't do that in the future! I'll reply to the more constructive thread. 
Acee

On 4/8/22, 4:45 PM, "Lsr on behalf of Randy Presuhn"  wrote:

Hi -

On 2022-04-08 12:25 PM, Acee Lindem (acee) wrote:
...
> If you look at the existing YANG RFCs rather than drafts that are 
confirming to the error, you'll notice that they don't use the no-zone types:
> 
> https://datatracker.ietf.org/doc/rfc8344/
...

Huh?  RFC 8344 *does* use inet:ipv4-address-no-zone
and inet:ipv6-address-no-zone.

> Also, if you look at the SNMP RFC 4001, you'll note that the base types 
do not include the zone index and RFC8344 references the MIB types using the 
base types (see snippet below).

RFC 4001 addresses the limitation of the IpAddress SMIv2 base type,
which is inherently unsuitable for IPv6 addresses.  The new address
types defined in RFC 4001 have OCTET STRING as their base type. The
"base type" relationship you seem to be inferring reads too
much into the labels, which are merely mnemonic.  One might argue
about the suitability of any particular (non)system of mnemonics,
but the nature of these beasts is that we can't significantly change
them once their published.

> Clearly, it was wrong to make the IP addresses including the zone the 
default

How is it a "default"?  Both zonable and zoneless types are available
to the model developer.  Nothing makes one or the other a default.

> and I'm not sure why there is all this effort not to just admit, fix the 
RFC 6991 BIS version, and be done with it.

30+ years of tradition (and BCP) not permitting types to be changed
after they've been published, I suppose, motivated by our total lack
of control over unpublished usage of these types after their definitions
have been published.

If there were actually something wrong with the semantics or syntax,
I'm sure there would be more sympathy for the argument.  But the heart
of the argument is that the types label's mnemonicity is poor.  That,
coupled with the collateral damage resulting from a "fix", makes
the whole argument terribly unpersuasive to me, particularly
when the definition in question was been published, implemented, and
deployed years ago.

Randy

___
Lsr mailing list
l...@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Andy Bierman]

On Sat, Apr 9, 2022 at 9:51 AM Randy Presuhn <
randy_pres...@alumni.stanford.edu> wrote:

> Hi -
>
> On 2022-04-09 4:36 AM, Christian Hopps wrote:
> ...
> > FWIW, I'm not arguing for this change; however, to be fair, isn't this
> > also about the existing published modules that are using the incorrect
> > type?
>
> No.  "Incorrect type" is a bit of a mischaracterization.  It's like
> saying using "int32" is incorrect if all that is needed is "uint16".
> One might say its a little sloppy or mutter "RTFM" under one's breath,
> but it's not "incorrect."
>
>
You and Martin convinced me the ip-address type cannot be changed.
There are other options.

If a YANG module is using ip-address, and the WG intent was really to
use ip-address-no-zone, then that module can be fixed with an Errata.
The modules should not need to be updated just for this incorrect typedef
usage.

The type names are unfortunate but in the future this will not happen again.



> Some modules have used a type that potentially can represent more
> values than are needed for the intended purpose.  Whether those
> implementations will ever accept or produce those values will
> depend on whether the code, whether library, generated, or hand-
> crafted, enforces the tighter constraints appropriate to the usage
> or only the looser constraints appropriate to the type's specification.
>
> But this is also true of every usage of any type where the use
> can only exhibit a subset of the possible values of the type,
> whether that subsetting is obvious from the description or not,
> so I find it really hard to get excited about it.  The more nuanced
> a repertoire of types becomes, the more likely developers won't
> use exactly the right one, though one would hope that these foibles
> are caught during the review process, at least until developers
> start reading the documentation for the libraries they employ.
>
>
There are many examples where the pattern allows more strings
than the intended usage.  Also, a server can reject any request for any
reason.

That does not address the conformance problem that Acee may be concerned
about.
What is a server required to support for a leaf with type ip-address?
The text does not look like the zone index is optional for the server to
accept.



> Even in these cases of "incorrect" usage, as Andy and others
> have pointed out, stuff still works, because those cases only
> require a subset of the values supported by the type.  If the
> proposed change is made, usages requiring the full value space of
> the original type definition will break, and those formerly
> "incorrect" usages will exhibit no change in their behavior.
>
>

It works because clients are not sending addresses with a zone index.
I agree with Martin that the NC/RC server is always obligated to reject a
request
it cannot fulfill, regardless of the typedef.



> That is, the proposed change does not improve operation of
> anything, and it breaks some things.
>
>
yes -- too many years out in the wild this way to switch type names around
now.



> For me, it's more important for stuff to work (and to not break
> stuff) than it is to align perfectly with the underlying aesthetics
> of some naming system attributed post hoc to a set of types.
>
> Randy
>

Andy


>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Randy Presuhn]

Hi -

On 2022-04-09 4:36 AM, Christian Hopps wrote:
...
FWIW, I'm not arguing for this change; however, to be fair, isn't this 
also about the existing published modules that are using the incorrect 
type?


No.  "Incorrect type" is a bit of a mischaracterization.  It's like
saying using "int32" is incorrect if all that is needed is "uint16".
One might say its a little sloppy or mutter "RTFM" under one's breath,
but it's not "incorrect."

Some modules have used a type that potentially can represent more
values than are needed for the intended purpose.  Whether those
implementations will ever accept or produce those values will
depend on whether the code, whether library, generated, or hand-
crafted, enforces the tighter constraints appropriate to the usage
or only the looser constraints appropriate to the type's specification.

But this is also true of every usage of any type where the use
can only exhibit a subset of the possible values of the type,
whether that subsetting is obvious from the description or not,
so I find it really hard to get excited about it.  The more nuanced
a repertoire of types becomes, the more likely developers won't
use exactly the right one, though one would hope that these foibles
are caught during the review process, at least until developers
start reading the documentation for the libraries they employ.

Even in these cases of "incorrect" usage, as Andy and others
have pointed out, stuff still works, because those cases only
require a subset of the values supported by the type.  If the
proposed change is made, usages requiring the full value space of
the original type definition will break, and those formerly
"incorrect" usages will exhibit no change in their behavior.

That is, the proposed change does not improve operation of
anything, and it breaks some things.

For me, it's more important for stuff to work (and to not break
stuff) than it is to align perfectly with the underlying aesthetics
of some naming system attributed post hoc to a set of types.

Randy

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IPR Poll on draft-ietf-netmod-node-tags-06

[Benoit Claise]

"No, I'm not aware of any IPR that applies to this draft"

Regards, Benoit



On 4/8/2022 8:09 PM, Kent Watsen wrote:

[ Note: existing IPR declaration: https://datatracker.ietf.org/ipr/4216 ]


Authors, Contributors, WG,

As part of WG Last Call:

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate. If you are listed as a document author or contributor
please answer the above by responding to this email regardless
of whether or not you are aware of any relevant IPR. This
document will not advance to the next stage until a response
has been received from each author.

NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.

If you are on the WG email list or attend WG meetings but are not
listed as an author or contributor, we remind you of your obligations
under the IETF IPR rules which encourages you to notify the IETF
if you are aware of IPR of others on an IETF contribution, or to
refrain from participating in any contribution or discussion related
to your undisclosed IPR. For more information, please see the RFCs
listed above and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
Kent (Co-Chair)

PS Please include all listed in the headers of this message in your
response.


.


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Christian Hopps]

Randy Presuhn  writes:

30+ years of tradition (and BCP) not permitting types to be changed
after they've been published, I suppose, motivated by our total lack
of control over unpublished usage of these types after their definitions
have been published.

If there were actually something wrong with the semantics or syntax,
I'm sure there would be more sympathy for the argument.  But the heart
of the argument is that the types label's mnemonicity is poor.  That,
coupled with the collateral damage resulting from a "fix", makes
the whole argument terribly unpersuasive to me, particularly
when the definition in question was been published, implemented, and
deployed years ago.


FWIW, I'm not arguing for this change; however, to be fair, isn't this also 
about the existing published modules that are using the incorrect type?

Thanks,
Chris.




Randy

___
Lsr mailing list
l...@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[tom petch]

From: tom petch 
Sent: 08 April 2022 17:32

From: Lsr  on behalf of Joel M. Halpern 

Sent: 07 April 2022 18:51

Given that you are asking for an incompatible change to an existing
module, the shoe would seem to be on the other foot.

If you could show it was necessary to make such an incompatible change,
then there would be a difficult argument to be had.  But you simply have
not shown it.  (And showing that no one uses the zone field would seem
the reasonable and impossible bar for doing such.)



I said previously that I saw the DHC and I2NSF WG consciously using no-zone but 
was not able to check for others.  I now can check, in part, and see detnet, 
MPLS and rtgwg using no-zone.  It may be that nvo3, sacm and intarea are other 
such WGs.

Interestingly, I recall one author saying that yes, they needed the zone format 
and I see that mldp uses a mix of zone and no-zone so that may have been the 
one I was remembering and it may be a case where a zone is required.  I would 
make sense for that protocol, as it would for other 'local' protocols, such as 
printing, problem determination and so on.


I see another use of no-zone in 
  draft-ietf-lsr-ospf-srv6-yang-01

so the LSR WG is, at times, a user of no-zone.

Tom Petch

Yours,
Joel

On 4/7/2022 1:22 PM, Acee Lindem (acee) wrote:
> Hi Joel,
>
> On 4/7/22, 1:18 PM, "Joel M. Halpern"  wrote:
>
>  Acee, I am missing something basic.
>  It seems to me that it would be very wrong for the LSR YANG module to
>  demand a change to an important type because it turns out that type
>  doesn't mean what LSR thought it meant.  Such an error is LSR's problem,
>  not the underlying modules.
>
>  There seem to be two fixes.  If it is for some reason imperitive to us
>  the same typedef we have been using, then put in text / patterns /
>  restrictions saying that this model MUST NOT use the scope field.
>
>  More reasonably, use a different typedef in this model.
>
> Point me to a usages where the zone is actually desired and supported?
>
> Acee
>
>
>
>
>  Yours,
>  Joel
>
>  On 4/7/2022 1:04 PM, Acee Lindem (acee) wrote:
>  > Hi Martin,
>  >
>  > On 4/7/22, 1:02 PM, "netmod on behalf of Martin Björklund" 
>  wrote:
>  >
>  >  Andy Bierman  wrote:
>  >  > On Thu, Apr 7, 2022 at 9:11 AM tom petch  
> wrote:
>  >  >
>  >  > > From: Lsr  on behalf of Rob Wilton 
> (rwilton)
>  >  > > 
>  >  > > Sent: 07 April 2022 10:25
>  >  > >
>  >  > > I basically agree with Acee, and I think that we should do 
> (b):
>  >  > >
>  >  > > b) Change the types as suggested and accept that 
> doing so breaks
>  >  > > modules where zone indexes are meaningful.
>  >  > >
>  >  > > 
>  >  > >
>  >  > > I am concerned that such behaviour will damage the standing 
> of the IETF at
>  >  > > large.
>  >  > >
>  >  > >
>  >  > MAY for the client means MUST for the server.
>  >
>  >  I'm not sure what you mean here.
>  >
>  >  But I'm also not sure I understand what the real problem is.  
> Just b/c
>  >  the type allows a zone doesn't mean that all leafs that use this 
> type
>  >  MUST support a zone.  Compare with the value "0.0.0.0".  It is a 
> legal
>  >  value according to the pattern, but it will not be valid in all 
> places
>  >  where this type is used.  And even when an implementation supports
>  >  zones, it will not accept all legal (according to the pattern) 
> values
>  >  for the zone index.  Perhaps the solution is to explain this
>  >  better in the description?
>  >
>  >
>  >  > But if no servers actually support it, because the YANG does 
> not match
>  >  > the operational requirements, then is it really a MUST 
> requirement?
>  >  >
>  >  > This seems like a bugfix, and the worst thing the IETF could do 
> wrt/
>  >  > standing
>  >  > is to force the world to change every module that imports the 
> typedef.
>  >  > Since many people were not aware of the full syntax, it is not 
> clear that
>  >  > the WG intent was to include a zone.
>  >
>  >  It is pretty clear IMO that this was not a mistake.  The text
>  >  explicitly says:
>  >
>  >The IPv4 address may include a zone
>  >index, separated by a % sign.
>  >
>  >  >
>  >  > Seems like a bugfix to a pattern, like we have done several 
> times already.
>  >
>  >  I don't think this is a bugfix.
>  >
>  > A bugfix for the requirements for the base types that requires fixing 
> the pattern and description.
>  >
>  > Acee
>  >
>  >
>  >  /martin
>  >
>  >
>  >  >
>  >  > Andy
>  >  >
>