Re: [netmod] Mirja Kühlewind's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS)
Mirja, See inline. On 9/25/18, 6:29 PM, "netmod on behalf of Mirja Kuehlewind (IETF)" wrote: Hi Mahesh, hi Eliot, please see below. > Am 25.09.2018 um 22:25 schrieb Eliot Lear : > > Just on this point: > > On 25.09.18 20:35, Mahesh Jethanandani wrote: >>> That’s do bad. However, the document must at least say that it’s scope is (sorry for the type… I meant to say „too bad“.) >>> restricted to TCP and UDP only and it would also be nice to reason why that restriction is and what would need to be done to extend it in future. >> >> To the contrary. The model is not restricted to TCP and UDP. In Section 2, the document states that: >> >>ACL implementations in every device may vary greatly in terms of the >>filter constructs and actions that they support. Therefore this >>draft proposes a model that can be augmented by standard extensions >>and vendor proprietary models. >> >> Yes, ACL implementations differ, however, the protocol spec for SCTP and DCCP don’t have different implementation; their are mostly fixed. Unfortunately, firewalls often just block any other traffic than TCP and UDP, and restricting such a model only to those protocols will definitely not help the situation. >> >> It is a different matter that it has chosen not to support SCTP and DCCP. That is because implementations today have not felt the market need to add support for those protocols. But that does not prevent anyone from adding support for them. If your YANG model does not support long-existent and well-specified protocols, that doesn’t make it any easier to add support for these protocols to your firewall. >> >> As far as an example for how the model can be extended in the future, see Appendix A - Extending ACL model examples. > > It's important to not try to boil the ocean, and this model is already boiling a rather large river. There's room for someone else to do more work. I know I did ;-) I would think that adding another well-specified protocols is actually only a limited effort. How many YANG models have you authored? This would be a great opportunity. However, I don’t want to enforce a lot of additional work if people are not interested in that. What I still would like to see in the document is to make clear that these protocols have not just beennot considered but some reasoning why only the currently supported protocols have been selected (in order to make the reader aware that this is not a full set). I would think pointing out that these protocols are out of scope would suffice. However, I'll leave that to the author. Thanks, Acee Mirja > > Eliot ___ 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] Mirja Kühlewind's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS)
Hi Mahesh, hi Eliot, please see below. > Am 25.09.2018 um 22:25 schrieb Eliot Lear : > > Just on this point: > > On 25.09.18 20:35, Mahesh Jethanandani wrote: >>> That’s do bad. However, the document must at least say that it’s scope is (sorry for the type… I meant to say „too bad“.) >>> restricted to TCP and UDP only and it would also be nice to reason why that >>> restriction is and what would need to be done to extend it in future. >> >> To the contrary. The model is not restricted to TCP and UDP. In Section 2, >> the document states that: >> >>ACL implementations in every device may vary greatly in terms of the >>filter constructs and actions that they support. Therefore this >>draft proposes a model that can be augmented by standard extensions >>and vendor proprietary models. >> >> Yes, ACL implementations differ, however, the protocol spec for SCTP and DCCP don’t have different implementation; their are mostly fixed. Unfortunately, firewalls often just block any other traffic than TCP and UDP, and restricting such a model only to those protocols will definitely not help the situation. >> >> It is a different matter that it has chosen not to support SCTP and DCCP. >> That is because implementations today have not felt the market need to add >> support for those protocols. But that does not prevent anyone from adding >> support for them. If your YANG model does not support long-existent and well-specified protocols, that doesn’t make it any easier to add support for these protocols to your firewall. >> >> As far as an example for how the model can be extended in the future, see >> Appendix A - Extending ACL model examples. > > It's important to not try to boil the ocean, and this model is already > boiling a rather large river. There's room for someone else to do more work. > I know I did ;-) I would think that adding another well-specified protocols is actually only a limited effort. However, I don’t want to enforce a lot of additional work if people are not interested in that. What I still would like to see in the document is to make clear that these protocols have not just been not considered but some reasoning why only the currently supported protocols have been selected (in order to make the reader aware that this is not a full set). Mirja > > Eliot ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Mirja Kühlewind's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS)
Just on this point: On 25.09.18 20:35, Mahesh Jethanandani wrote: >> That’s do bad. However, the document must at least say that it’s >> scope is restricted to TCP and UDP only and it would also be nice to >> reason why that restriction is and what would need to be done to >> extend it in future. > > To the contrary. The model is *not* restricted to TCP and UDP. In > Section 2, the document states that: > >ACL implementations in every device may vary greatly in terms of the >filter constructs and actions that they support. Therefore this >draft proposes a model that can be augmented by standard extensions >and vendor proprietary models. > > > It is a different matter that it has chosen not to support SCTP and > DCCP. That is because implementations today have not felt the market > need to add support for those protocols. But that does not prevent > anyone from adding support for them. > > As far as an example for how the model can be extended in the future, > see Appendix A - Extending ACL model examples. It's important to not try to boil the ocean, and this model is already boiling a rather large river. There's room for someone else to do more work. I know I did ;-) Eliot signature.asc Description: OpenPGP digital signature ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Opsdir telechat review of draft-ietf-netmod-acl-model-19
> On Sep 25, 2018, at 12:32 PM, Joe Clarke wrote: > > Reviewer: Joe Clarke > Review result: Has Nits > > I have been assigned to review this document on behalf of the ops > directorate. > This document defines a YANG model for configuring access control lists (ACLs) > as well as other modules for protocol data types and ether types. Related to > those, it requests IANA actions to register the modules. > > This document is ready, and I only found a few nits in it. > > Section 1: > > s/criteria allows/criteria allow/ as criteria is plural > > s/criteria is/criteria are/ Ok. > > === > > Section 3: > > s/criteria allows/criteria allows/ You mean s/criteria allows/criteria allow/ I see one more (in Section 4.2) that I will correct also. > > === > > Section 7: > > s/together to created a/together to create a/ Ok. > > === > > Section A.3: > > Why is this module not yang-version 1.1 like the other two? Ok. > > > ___ > 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
[netmod] Opsdir telechat review of draft-ietf-netmod-acl-model-19
Reviewer: Joe Clarke Review result: Has Nits I have been assigned to review this document on behalf of the ops directorate. This document defines a YANG model for configuring access control lists (ACLs) as well as other modules for protocol data types and ether types. Related to those, it requests IANA actions to register the modules. This document is ready, and I only found a few nits in it. Section 1: s/criteria allows/criteria allow/ as criteria is plural s/criteria is/criteria are/ === Section 3: s/criteria allows/criteria allows/ === Section 7: s/together to created a/together to create a/ === Section A.3: Why is this module not yang-version 1.1 like the other two? ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Mirja Kühlewind's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS)
Hi Mirja, See responses inline. > On Sep 25, 2018, at 2:32 AM, Mirja Kuehlewind (IETF) > wrote: > > Hi Mahesh, > > please see below. > >> Am 25.09.2018 um 00:56 schrieb Mahesh Jethanandani : >> >> >> >>> On Sep 21, 2018, at 6:47 AM, Mirja Kühlewind wrote: >>> >>> Mirja Kühlewind 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: >>> -- >>> >>> 1) The tcp options element is type uint32, however, the option field in the >>> TCP >>> header can be up to 40 bytes. >> >> You are right that the options field can be up to 40 bytes long. >> >> To the WG - We have two options in front of us. Take the field out >> completely or change the type to binary, and add a ‘length’ restriction of >> 40. Unless there is a objection, we will go with the latter option. > > Not sure what exactly you mean but change the type to binary and add a length > restriction but I’ll leave it to you to have the appropriate change. Ok. > >> >>> >>> 2) Why are only TCP and UDP supported? What's about SCTP and DCCP? >> >> There has been no requirement to support either of those protocols. Support >> for those protocols can be added as augmentations to the base model in the >> future if such a need arises. > > That’s do bad. However, the document must at least say that it’s scope is > restricted to TCP and UDP only and it would also be nice to reason why that > restriction is and what would need to be done to extend it in future. To the contrary. The model is not restricted to TCP and UDP. In Section 2, the document states that: ACL implementations in every device may vary greatly in terms of the filter constructs and actions that they support. Therefore this draft proposes a model that can be augmented by standard extensions and vendor proprietary models. It is a different matter that it has chosen not to support SCTP and DCCP. That is because implementations today have not felt the market need to add support for those protocols. But that does not prevent anyone from adding support for them. As far as an example for how the model can be extended in the future, see Appendix A - Extending ACL model examples. > >> >>> >>> 3) The icmp rest-of-header can also be larger than 4 bytes but the type is >>> uint32 again. >> >> You are right that the rest-of-header can be more than 4 bytes, but in >> reality we have not had a requirement to support more than 4 bytes. >> >> To the WG - We will give it the same treatment as above - two options. Take >> it out completely, or change this to binary also. The only difference is >> that there does not seem to be a length restriction on the size of the >> field, so the field will be left unbounded. Unless there is a objection, we >> will go with the conversion to binary option. > > Again, leaving it to you to apply the appropriate fix. Ok. Thanks. > > Mirja > > > >> >> Cheers. ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] New Version Notification for draft-kwatsen-netmod-artwork-folding-07.txt
Original Message - From: "Kent Watsen" Sent: Monday, September 24, 2018 9:49 PM > Hi Tom, > > > I would like a paragraph in this I-D to the effect that editors should > > take care of this and that this phenomenon is nothing to do with the > > technique described here, a sort of non-Applicability statement so that > > we do not, in future, get too long lines as > > > > /* optical interface func needs to expand for Fiber Channel,\ > > \ SONET and SDH */ > > > > instead of turning them into > > > > /* optical interface func needs to expand > > for Fiber Channel, SONET and SDH */ > > Section 4.2 addresses this. In particular, the last line says: > > As such, it is RECOMMENDED that authors do as much as possible within > the selected format to avoid long lines. > > Good enough? No:-) The authors of YANG modules seem not to understand that it applies to them, or incorrectly use the tools that would apply were they correctly used. I had in mind something such as OLD [RFC7994][RFC7994]sets out the requirements for plain-text RFCs and states that each line of an RFC (and hence of an Internet-Draft) must be limited to 72 characters followed by the character sequence that denotes an end-of-line (EOL). NEW [RFC7994]sets out the requirements for plain-text RFCs and states that each line of an RFC (and hence of an Internet-Draft) must be limited to 72 characters followed by the character sequence that denotes an end-of-line (EOL). This applies to all of an RFC, including, for example, the comments or description clauses in a YANG module, and to artwork. Not sure why you have [RFC7994] twice. Tom Petch > Kent // contributor > ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Mirja Kühlewind's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS)
Hi Mahesh, please see below. > Am 25.09.2018 um 00:56 schrieb Mahesh Jethanandani : > > > >> On Sep 21, 2018, at 6:47 AM, Mirja Kühlewind wrote: >> >> Mirja Kühlewind 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: >> -- >> >> 1) The tcp options element is type uint32, however, the option field in the >> TCP >> header can be up to 40 bytes. > > You are right that the options field can be up to 40 bytes long. > > To the WG - We have two options in front of us. Take the field out completely > or change the type to binary, and add a ‘length’ restriction of 40. Unless > there is a objection, we will go with the latter option. Not sure what exactly you mean but change the type to binary and add a length restriction but I’ll leave it to you to have the appropriate change. > >> >> 2) Why are only TCP and UDP supported? What's about SCTP and DCCP? > > There has been no requirement to support either of those protocols. Support > for those protocols can be added as augmentations to the base model in the > future if such a need arises. That’s do bad. However, the document must at least say that it’s scope is restricted to TCP and UDP only and it would also be nice to reason why that restriction is and what would need to be done to extend it in future. > >> >> 3) The icmp rest-of-header can also be larger than 4 bytes but the type is >> uint32 again. > > You are right that the rest-of-header can be more than 4 bytes, but in > reality we have not had a requirement to support more than 4 bytes. > > To the WG - We will give it the same treatment as above - two options. Take > it out completely, or change this to binary also. The only difference is that > there does not seem to be a length restriction on the size of the field, so > the field will be left unbounded. Unless there is a objection, we will go > with the conversion to binary option. Again, leaving it to you to apply the appropriate fix. Mirja > > Cheers. > >> >> >> >> > ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
