[netmod] Suresh Krishnan's No Objection on draft-ietf-netmod-artwork-folding-10: (with COMMENT)
Suresh Krishnan has entered the following ballot position for draft-ietf-netmod-artwork-folding-10: 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-netmod-artwork-folding/ -- COMMENT: -- I am happy with this progressing as an Informational document. ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] Suresh Krishnan's Discuss on draft-ietf-netmod-artwork-folding-09: (with DISCUSS and COMMENT)
Suresh Krishnan has entered the following ballot position for draft-ietf-netmod-artwork-folding-09: 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 IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/ -- DISCUSS: -- After some thought I think there are two things about this document that make me uncomfortable enough to ballot Discuss. a) Due to its home in the netmod WG it is highly likely that people outside the yang community have not paid enough attention to this work. Since this is applicable to code fragments of all kinds, I think the home chosen for this RFC might have inadvertently limited input from the broader community. b) Given a) I think it is better that this document go forward as an Informational document rather than a BCP so that use of this technique becomes optional, without the force of a BCP behind it. -- COMMENT: -- I do agree with my Abstaining colleagues that this should probably not be on the IETF stream but I think the work is useful enough to go forward. ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] Suresh Krishnan's No Objection on draft-ietf-netmod-schema-mount-11: (with COMMENT)
Suresh Krishnan has entered the following ballot position for draft-ietf-netmod-schema-mount-11: 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-netmod-schema-mount/ -- COMMENT: -- Section 3.3. I think it would be nice to have some examples to illustrate the differences between inline and shared-schema and some guidance to pick between the two. ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] Suresh Krishnan's No Objection on draft-ietf-netmod-acl-model-20: (with COMMENT)
Suresh Krishnan has entered the following ballot position for draft-ietf-netmod-acl-model-20: 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-netmod-acl-model/ -- COMMENT: -- Thanks for addressing my DISCUSS point. ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Suresh Krishnan's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS)
> On Sep 27, 2018, at 6:36 PM, Mahesh Jethanandani > wrote: > > > >> On Sep 26, 2018, at 9:36 PM, Suresh Krishnan wrote: >> >> Suresh Krishnan has entered the following ballot position for >> draft-ietf-netmod-acl-model-19: 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 IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ >> >> >> >> -- >> DISCUSS: >> -- >> >> This document is missing ACL handling for ICMPv6 (RFC4443) completely. As the >> ICMP types and codes are different for ICMP and ICMPv6 I think this model >> should be included to cover ICMPv6. > > In offline discussions with Suresh, here is what we agreed I would do to > address this DISCUSS: > > - Update the rest-of-header field in ICMP grouping from ‘type uint32’ to > ‘type binary’, as already agreed, to address Mirja’s DISCUSS. The field will > be unbounded. > - Add a reference to RFC 4443 in the grouping. > - At this point the grouping should be able to cater to both icmpv4 and > icmpv6 match requirements. Yep. That would handle the issue perfectly well. I will clear as soon as the next rev hits. Thanks Suresh ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Suresh Krishnan's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS)
Hi Mahesh, Thanks for your quick reply. Please find comments inline. > On Sep 27, 2018, at 12:57 AM, Mahesh Jethanandani > wrote: > > Hi Suresh, > >> On Sep 26, 2018, at 9:36 PM, Suresh Krishnan wrote: >> >> Suresh Krishnan has entered the following ballot position for >> draft-ietf-netmod-acl-model-19: 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 IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ >> >> >> >> -- >> DISCUSS: >> -- >> >> This document is missing ACL handling for ICMPv6 (RFC4443) completely. As the >> ICMP types and codes are different for ICMP and ICMPv6 I think this model >> should be included to cover ICMPv6. > > I understand that there are many protocols that fall into such a criteria. As > has already been discussed, we are offering the minimum set of protocols for > which there is a demand, while giving the option to extend it through > augmentations of the base model. I understand where you are coming from but ICMPv6 is not just another protocol. It is a core protocol in the IPv6 protocol suite. Do you know of any systems that support IPv6 acls but not support ICMPv6 there? > > Let us not boil the ocean. As it is, this draft has been in the works for > more than 4 years. This is a very clear and bounded request (i.e. not boiling the ocean). I do not think this will be significant amount of work. If you do feel otherwise, I will be glad to revisit my position Regards Suresh ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] Suresh Krishnan's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS)
Suresh Krishnan has entered the following ballot position for draft-ietf-netmod-acl-model-19: 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 IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ -- DISCUSS: -- This document is missing ACL handling for ICMPv6 (RFC4443) completely. As the ICMP types and codes are different for ICMP and ICMPv6 I think this model should be included to cover ICMPv6. ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] Suresh Krishnan's No Objection on draft-ietf-netmod-rfc6087bis-19: (with COMMENT)
Suresh Krishnan has entered the following ballot position for draft-ietf-netmod-rfc6087bis-19: 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-netmod-rfc6087bis/ -- COMMENT: -- Thanks for addressing my DISCUSS and COMMENT points. ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Suresh Krishnan's Discuss on draft-ietf-netmod-rfc6087bis-18: (with DISCUSS and COMMENT)
Hi Andy/Benoit,
Your suggested changes look good to me. I will clear as soon as the new
version hits.
Regards
Suresh
On Mar 7, 2018, at 5:24 AM, Benoit Claise
<bcla...@cisco.com<mailto:bcla...@cisco.com>> wrote:
Suresh,
On Tue, Mar 6, 2018 at 8:44 PM, Suresh Krishnan
<sur...@kaloom.com<mailto:sur...@kaloom.com>> wrote:
Suresh Krishnan has entered the following ballot position for
draft-ietf-netmod-rfc6087bis-18: 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 IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/
--
DISCUSS:
--
* Section 4.25
I think this might be a simple misunderstanding but I have no idea what
compliance with this statement implies.
"A YANG module MUST NOT be designed such that the set of modules found on a
server implementation can be predetermined in advance."
Can you please clarify?
OK to remove this sentence.
Not sure where it came from
--
COMMENT:
--
Section 3.2:
The date looks to be contradictory between the explanatory text
"The following example is for the '2010-01-18' revision of the 'ietf-foo'
module:"
and the actual code component defined right after
file
"ietf-...@2016-03-20.yang"<mailto:ietf-...@2016-03-20.yang>
...
revision 2016-03-20 {
...
OK will update revision date
* Section 4.8
I went over this text several times to figure out what it means. Can you
simplify this, or provide examples as to when revision dates are/are not to be
updated.
It is not required to keep the full revision history of draft
versions (e.g., modules contained within Internet-Drafts). That is,
within a sequence of draft versions, only the most recent revision
need be recorded in the module. However, whenever a new (i.e.
changed) version is made available (e.g., via a new version of an
Internet-Draft), the revision date of that new version MUST be
updated to a date later than that of the previous version.
OK -- will clarify that the same revision-stmt can be reused in an Internet
Draft.
The revision date is updated if the module is changed.
What we mean here is that the published RFC should contain something such as:
revision 2018-01-09 {
description
"Updated to support NMDA.";
reference
"RFC : A YANG Data Model for Interface Management";
}
As opposed to the full draft history and change log
revision 2018-01-09 {
description
"Updated to support NMDA.";
reference
"RFC : A YANG Data Model for Interface Management";
}
revision 2017-11-01 {
description
"Updated to address AD review.";
reference
"draft-ietf-netmod-rfc7223bis-03";
}
revision 2017-09-01 {
description
"Updated to address issue X, Y, Z";
reference
"draft-ietf-netmod-rfc7223bis-02";
}
* Section 4.20
What does "cannot" imply here? MUST NOT? SHOULD NOT?
MUST NOT -- per RFC 7950, 7.20.3
"The YANG "deviation" statement cannot appear in IETF YANG modules"
Will change "cannot" to is not allowed to"
There is not point to repeat the RFC7950 specifications, but we want to add to
it.
Therefore, let me propose:
OLD:
The YANG "deviation" statement cannot appear in IETF YANG modules,
but it can be useful for documenting server capabilities. Deviation
statements are not reusable and typically not shared across all
platforms.
NEW:
Per RFC 7950, 7.20.3, the YANG "deviation" statement is not allowed to
appear in IETF YANG modules,
but it can be useful for documenting server capabilities. Deviation
statements are not reusable and typically not shared across all
platforms.
Regards, Benoit
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
[netmod] Suresh Krishnan's Discuss on draft-ietf-netmod-rfc6087bis-18: (with DISCUSS and COMMENT)
Suresh Krishnan has entered the following ballot position for
draft-ietf-netmod-rfc6087bis-18: 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 IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/
--
DISCUSS:
--
* Section 4.25
I think this might be a simple misunderstanding but I have no idea what
compliance with this statement implies.
"A YANG module MUST NOT be designed such that the set of modules found on a
server implementation can be predetermined in advance."
Can you please clarify?
--
COMMENT:
--
Section 3.2:
The date looks to be contradictory between the explanatory text
"The following example is for the '2010-01-18' revision of the 'ietf-foo'
module:"
and the actual code component defined right after
file "ietf-...@2016-03-20.yang"
...
revision 2016-03-20 {
...
* Section 4.8
I went over this text several times to figure out what it means. Can you
simplify this, or provide examples as to when revision dates are/are not to be
updated.
It is not required to keep the full revision history of draft
versions (e.g., modules contained within Internet-Drafts). That is,
within a sequence of draft versions, only the most recent revision
need be recorded in the module. However, whenever a new (i.e.
changed) version is made available (e.g., via a new version of an
Internet-Draft), the revision date of that new version MUST be
updated to a date later than that of the previous version.
* Section 4.14.1. Non-Presence Container
So what is the guideline here? That there is no guideline?
* Section 4.20
What does "cannot" imply here? MUST NOT? SHOULD NOT?
"The YANG "deviation" statement cannot appear in IETF YANG modules"
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
[netmod] Suresh Krishnan's No Objection on draft-ietf-netmod-rfc8022bis-09: (with COMMENT)
Suresh Krishnan has entered the following ballot position for
draft-ietf-netmod-rfc8022bis-09: 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-netmod-rfc8022bis/
--
COMMENT:
--
* Lots of places in the document where NMDA is misspelled as NDMA. Please fix.
* Section 9.1.
The ranges for AdvDefaultLifetime and MaxRtrAdvInterval have been changed by
RFC-to-be-8319 to update the values specified in RFC4861. Please change these
ranges to the new values.
OLD:
leaf max-rtr-adv-interval {
type uint16 {
range "4..1800";
}
NEW:
leaf max-rtr-adv-interval {
type uint16 {
range "4..65535";
}
OLD:
leaf default-lifetime {
type uint16 {
range "0..9000";
}
NEW:
leaf default-lifetime {
type uint16 {
range "0..65535";
}
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
[netmod] Suresh Krishnan's No Objection on draft-ietf-netmod-routing-cfg-24: (with COMMENT)
Suresh Krishnan has entered the following ballot position for draft-ietf-netmod-routing-cfg-24: 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-netmod-routing-cfg/ -- COMMENT: -- * Have you considered including support for the Route Information Option (RFC4191)? Seems like it would be useful. * default-lifetime is defined with a range of 0..9000 in this document but the upper limit will be raised to 65535 if and when draft-ietf-6man-maxra is approved. Is there a mechanism by which you can easily support this increased upper limit? ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] Suresh Krishnan's No Objection on draft-ietf-netmod-rfc6020bis-12: (with COMMENT)
Suresh Krishnan has entered the following ballot position for
draft-ietf-netmod-rfc6020bis-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 IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/
--
COMMENT:
--
Meta comment:
Shouldn't this document obsolete RFC6060. There is no Obsoletes: tag in
the draft
Section 4.2.4:
s/A reference a data tree node/A reference to a data tree node
Section 9.4.7:
It is not clear why the following refinement is illegal. Can you
clarify?
type my-base-str-type {
// illegal length refinement
length "1..999";
}
IANA considerations:
Not sure what is the correct method for doing this in -bis documents, but
I would have expected a note that instructs IANA to switch references to
RFC6020 in IANA registries over to this one.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
