[OPSAWG] Francesca Palombini's No Objection on draft-ietf-opsawg-tlstm-update-12: (with COMMENT)
Francesca Palombini has entered the following ballot position for draft-ietf-opsawg-tlstm-update-12: 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/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-opsawg-tlstm-update/ -- COMMENT: -- Thank you for the work on this document. I was going to have the same comment as Roman's first point. Additionally, and in any case, it would be good in my opinion to expand the Expert Guidelines, as the only guideline right now is "consult the security area" (and even then, it's only encouraged). For more input about what I think should be there, RFC 8126 says it best: The required documentation and review criteria, giving clear guidance to the designated expert, should be provided when defining the registry. **It is particularly important to lay out what should be considered when performing an evaluation and reasons for rejecting a request.** It is also a good idea to include, when possible, a sense of whether many registrations are expected over time, or if the registry is expected to be updated infrequently or in exceptional circumstances only. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Francesca Palombini's No Objection on draft-ietf-opsawg-l2nm-17: (with COMMENT)
Francesca Palombini has entered the following ballot position for
draft-ietf-opsawg-l2nm-17: 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/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-opsawg-l2nm/
--
COMMENT:
--
# ART AD Review of draft-ietf-opsawg-l2nm-17
cc @fpalombini
Thank you for the work on this document.
I have a couple of comments, hopefully easy to fix.
I have not finished reviewing the examples in appendix, I might update this
ballot if I have additional comments.
Francesca
## Comments
### boolean for enabled/disabled
Section 8.4:
```
"Controls whether loss measurement is enabled/disabled.";
```
```
"Controls whether ingress replication is
enabled/disabled.";
```
```
"Controles whether P2MP replication is
enabled/disabled.";
```
Suggest rephrasing for clarity as other boolean fields: "Controls whether X is
enabled ('true') or disabled ('false').";
### needs a language tag
Section 8.4:
```
leaf description {
type string;
description
"A textual description of the VPN network
access.";
```
```
leaf description {
type string;
description
"Textual description of a VPN node.";
}
```
As these fields contain human-readable text, I believe it might need a language
tag, or specify why a tag is not needed, as specified by RFC 5646. I think that
such a tag is not necessary for pw-description and vpn-description as, if I
read them correctly, that is covered by the docs where those are initially
defined (for example, for pw-description, this is covered by the last paragraph
of section 5.5 of RFC 4447). Do let me know if I missed these
vpn-network-access description and vpn-node description, and their language are
also described here or inherited from another doc.
## Notes
This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.
[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Francesca Palombini's Discuss on draft-ietf-opsawg-l3sm-l3nm-16: (with DISCUSS and COMMENT)
Francesca Palombini has entered the following ballot position for
draft-ietf-opsawg-l3sm-l3nm-16: 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/blog/handling-iesg-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-opsawg-l3sm-l3nm/
--
DISCUSS:
--
Thank you for the work on this document, and apologies for the delayed review.
I have one DISCUSS point, a couple of comments.
As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion; I really think that the
document would be improved with a change here, but can be convinced otherwise.
I have divided comments into "minor" (including the questions) and "nits".
Neither require replies strictly speaking, please feel free to address as you
see fit. I will appreciate answers to my questions, to improve my
understanding. If any clarification comes out of it, I hope it will help
improve the document.
Francesca
1. -
leaf holdtime {
type uint32;
units "msec";
FP: This might be me not finding the right reference (or little knowledge of
YANG), but I was wondering if "msec" was defined somewhere as a unit (note that
the description does not mention that the unit is milliseconds either).
While doing my due diligence to see if I missed or misunderstood something, I
researched the RFCs mentioned in the beginning of the YANG module:
This module uses types defined in [RFC6991] and [RFC8343]. It also
uses groupings defined in [RFC8519], [RFC8177], and [RFC8294].
And found no use of the "msec" unit. A quick google search shows that RFC 8299
uses it, so there is precedence for it, but I couldn't find its definition from
that document either. All the other leaves use "milliseconds" (which is defined
in RFC 8294), so my preference would be to have consistency, if "msec" was
defined and I just missed it.
(Note that a similar remark could be made for "bps" used, which does not appear
in the description text, and is also used in RFC 8466, however there is no
issue about consistency there).
--
COMMENT:
--
## Minor
2. -
'status': Indicates the status of the OSPF routing instance.
FP: Most likely a copy-paste leftover in section 7.6.3.4 should be IS-IS
instead of OSPF.
3. -
Section 7.6.3.5, re timers
FP: shouldn't the units be explicitly stated in the timers description text, or
are they defined somewhere else? Actually, I can see the unit is specified
later on in the YANG module - so my suggestion is to add some simple text in
7.6.3.5 to explicitly say that the timers are in seconds.
4. -
leaf required-min-rx-interval {
FP: I see that RFC 5880 does not specify a default value for this; is there
really no default that can be specified here?
## Nits
5. -
"It is included only when enryption
is enabled.";
}
FP: typo s/enryption/encryption
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Francesca Palombini's No Objection on draft-ietf-opsawg-finding-geofeeds-12: (with COMMENT)
Francesca Palombini has entered the following ballot position for draft-ietf-opsawg-finding-geofeeds-12: 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-finding-geofeeds/ -- COMMENT: -- Thanks for addressing my DISCUSS and answering my question. Thank you for the work on this document, and thank you to the shepherd for a very well-written and in-depth shepherd write up: it was very informative and very appreciated. Francesca ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Francesca Palombini's Discuss on draft-ietf-opsawg-tacacs-yang-10: (with DISCUSS)
Francesca Palombini has entered the following ballot position for draft-ietf-opsawg-tacacs-yang-10: 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/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-yang/ -- DISCUSS: -- Thank you for the work on this document. This is a discuss DISCUSS - while reading this document and considering the normative downref to RFC 8907 TACACS+, which is informational, I agree with Elliot [1] that to me this document would make more sense as informational. I have followed the mail thread and saw the authors' responses, which quoted RFC 3967 : o A standards document may need to refer to a proprietary protocol, and the IETF normally documents proprietary protocols using informational RFCs. I am not convinced that this is one of the cases that this bullet was supposed to cover. Additionally, I could not find in meeting minutes that this was ever discussed in the wg, as was suggested in the mail thread [2]. I'd like to know if the resp AD is aware of any related discussion after this point was raised. Another point the authors made in favor of keeping this std track was that they haven't seen any YANG data model published as informational. Again, I am not convinced that this is reason enough to progress this as std track. I note that this was reported in the shepherd write up [3] and in the last call [4], so won't block progress after a discussion, but I do think it is worth talking about. Please let me know if I missed anything. Thanks, Francesca [1] https://mailarchive.ietf.org/arch/msg/opsawg/2mRkaXy5M9XCPp4_wXNpQd9GLdk/ [2] https://mailarchive.ietf.org/arch/msg/opsawg/MOnCfYBS3j4wBnZWDjl_YQHfvzg/ [3] https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-yang/shepherdwriteup/ [4] https://mailarchive.ietf.org/arch/msg/opsawg/FJmtUtB0x8tV0MUdO9Uhvc2e1p0/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
