Re: [Lsr] Adam Roach's No Objection on draft-ietf-isis-yang-isis-cfg-40: (with COMMENT)
Hi Chris,
We made this change in -41.
Thanks,
Acee
On 10/8/19, 6:14 AM, "Christian Hopps" wrote:
should have read "or it supports more than 32"
> On Oct 8, 2019, at 5:53 AM, Christian Hopps wrote:
>
> This strikes me as one of these artificial limits that gains us almost
nothing (what if the platform supports less than 32 or it supports 32?), and
creates these backward incompatible YANG issues (ranges that have to change)
that are part of what is driving the complexity in the YANG versioning stuff.
Why don't we just have a no range u16 or a 1..max range?
> Thanks,
> Chris.
>
>> On Oct 7, 2019, at 12:44 PM, Acee Lindem (acee) wrote:
>>
>>> grouping spf-parameters {
>>>container spf-control {
>>>leaf paths {
>>> if-feature max-ecmp;
>>> type uint16 {
>>>range "1..32";
>>> }
>>
>> Why is this a uint16 rather than a uint8?
>>
>> It definitely could be uint8.
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Adam Roach's No Objection on draft-ietf-isis-yang-isis-cfg-40: (with COMMENT)
should have read "or it supports more than 32"
> On Oct 8, 2019, at 5:53 AM, Christian Hopps wrote:
>
> This strikes me as one of these artificial limits that gains us almost
> nothing (what if the platform supports less than 32 or it supports 32?), and
> creates these backward incompatible YANG issues (ranges that have to change)
> that are part of what is driving the complexity in the YANG versioning stuff.
> Why don't we just have a no range u16 or a 1..max range?
> Thanks,
> Chris.
>
>> On Oct 7, 2019, at 12:44 PM, Acee Lindem (acee) wrote:
>>
>>> grouping spf-parameters {
>>>container spf-control {
>>>leaf paths {
>>> if-feature max-ecmp;
>>> type uint16 {
>>>range "1..32";
>>> }
>>
>> Why is this a uint16 rather than a uint8?
>>
>> It definitely could be uint8.
>
signature.asc
Description: Message signed with OpenPGP
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Adam Roach's No Objection on draft-ietf-isis-yang-isis-cfg-40: (with COMMENT)
This strikes me as one of these artificial limits that gains us almost nothing
(what if the platform supports less than 32 or it supports 32?), and creates
these backward incompatible YANG issues (ranges that have to change) that are
part of what is driving the complexity in the YANG versioning stuff. Why don't
we just have a no range u16 or a 1..max range?
Thanks,
Chris.
> On Oct 7, 2019, at 12:44 PM, Acee Lindem (acee) wrote:
>
>> grouping spf-parameters {
>> container spf-control {
>> leaf paths {
>> if-feature max-ecmp;
>> type uint16 {
>> range "1..32";
>> }
>
>Why is this a uint16 rather than a uint8?
>
> It definitely could be uint8.
signature.asc
Description: Message signed with OpenPGP
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Adam Roach's No Objection on draft-ietf-isis-yang-isis-cfg-40: (with COMMENT)
Hi Adam,
Thanks for review.
On 10/2/19, 6:31 PM, "Adam Roach via Datatracker" wrote:
Adam Roach has entered the following ballot position for
draft-ietf-isis-yang-isis-cfg-40: No Objection
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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-isis-yang-isis-cfg/
--
COMMENT:
--
Thanks for the work that went into this model. I have only a handful
of minor issues I found when reading through the module.
---
>grouping spf-parameters {
> container spf-control {
> leaf paths {
>if-feature max-ecmp;
>type uint16 {
> range "1..32";
>}
Why is this a uint16 rather than a uint8?
It definitely could be uint8.
---
> leaf-list tag {
>type uint32;
>description
> "List of 32-bit tags associated with the IPv4 prefix.";
> }
> leaf-list tag64 {
>type uint64;
>description
> "List of 32-bit tags associated with the IPv4 prefix.";
> }
I think this second description is meant to say "64-bit" rather than
"32-bit".
Fixed and will be in the -41 version.
---
> leaf reason {
>type string {
> length "1..255";
>}
>description
> "The system may provide a reason to reject the
> adjacency. If the reason is not available,
> an empty string will be returned.
> The expected format is a single line text.";
> }
This description is inconsistent with the definition: it calls for an empty
string, while the definition requires that at lest one character be
present. If
you want to keep the description as-is, you need to adjust the length to be
"0..255". Alternately, you might indicate that the field is simply to be
omitted rather than empty, which appears to be the intention for other
"reason" fields in this model.
Actually, I think the intension was to return a string consisting solely of the
EOL character ('\0'). However, I think not returning a string is a better
alternative.
Thanks
Acee
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Adam Roach's No Objection on draft-ietf-isis-yang-isis-cfg-40: (with COMMENT)
Adam Roach has entered the following ballot position for
draft-ietf-isis-yang-isis-cfg-40: No Objection
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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-isis-yang-isis-cfg/
--
COMMENT:
--
Thanks for the work that went into this model. I have only a handful
of minor issues I found when reading through the module.
---
>grouping spf-parameters {
> container spf-control {
> leaf paths {
>if-feature max-ecmp;
>type uint16 {
> range "1..32";
>}
Why is this a uint16 rather than a uint8?
---
> leaf-list tag {
>type uint32;
>description
> "List of 32-bit tags associated with the IPv4 prefix.";
> }
> leaf-list tag64 {
>type uint64;
>description
> "List of 32-bit tags associated with the IPv4 prefix.";
> }
I think this second description is meant to say "64-bit" rather than "32-bit".
---
> leaf reason {
>type string {
> length "1..255";
>}
>description
> "The system may provide a reason to reject the
> adjacency. If the reason is not available,
> an empty string will be returned.
> The expected format is a single line text.";
> }
This description is inconsistent with the definition: it calls for an empty
string, while the definition requires that at lest one character be present. If
you want to keep the description as-is, you need to adjust the length to be
"0..255". Alternately, you might indicate that the field is simply to be
omitted rather than empty, which appears to be the intention for other
"reason" fields in this model.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
