[IPsec] Zaheduzzaman Sarker's Yes on draft-ietf-ipsecme-add-ike-13: (with COMMENT)
Zaheduzzaman Sarker has entered the following ballot position for draft-ietf-ipsecme-add-ike-13: Yes 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-ipsecme-add-ike/ -- COMMENT: -- Thanks for addressing my discuss comments.. the -13 looks good to me. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Zaheduzzaman Sarker's Discuss on draft-ietf-ipsecme-add-ike-11: (with DISCUSS)
Zaheduzzaman Sarker has entered the following ballot position for draft-ietf-ipsecme-add-ike-11: 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/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-ipsecme-add-ike/ -- DISCUSS: -- Thanks for working on this specification. I don't have transport related issues on this specification. However, this specification relaxes constrains imposed by RFC8598 but references it informatively. I think it should reference RFC8598 as normative reference and also should clearly indicate that in the document header and abstract. I am assuming this is an oversight but want to discuss it. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Zaheduzzaman Sarker's No Objection on draft-ietf-ipsecme-mib-iptfs-10: (with COMMENT)
Zaheduzzaman Sarker has entered the following ballot position for draft-ietf-ipsecme-mib-iptfs-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/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-ipsecme-mib-iptfs/ -- COMMENT: -- Thanks for addressing my discuss points. Thanks to Brian Trammell for his TSVART review and I agree with this observations. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Zaheduzzaman Sarker's Discuss on draft-ietf-ipsecme-mib-iptfs-08: (with DISCUSS and COMMENT)
Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-ipsecme-mib-iptfs-08: 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/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-ipsecme-mib-iptfs/
--
DISCUSS:
--
Thanks for working on this specification.
I am balloting a Discuss, so that we pick the correct default value of
congestionControl object.
- Section 4.2 says
congestionControl OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"When set to true, the default, this enables the
congestion control on-the-wire exchange of data that is
required by congestion control algorithms as defined by
RFC 5348. When set to false, IP-TFS sends fixed-sized
packets over an IP-TFS tunnel at a constant rate."
DEFVAL { false }
::= { iptfsConfigTableEntry 2 }
While the description says the default value should be true, the DEFVAL
mentions "false".
--
COMMENT:
--
Thanks to Brian Trammell for his TSVART review and I agree with this
observations.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Zaheduzzaman Sarker's No Objection on draft-ietf-ipsecme-iptfs-19: (with COMMENT)
Zaheduzzaman Sarker has entered the following ballot position for draft-ietf-ipsecme-iptfs-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/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-ipsecme-iptfs/ -- COMMENT: -- Thanks for addressing my discuss points. The resolution looks good. However, I have small regret that the following comments were not addressed which I believe would add more clarity to the specification. # Section 2.4: I would like to have rational behind the two mode of operations. what are the pros and cons and when would an implementer select one over another? if this is written somewhere else then having a point would be great benefit. # Section 2.4.1: The failure correction due to the expected bandwidth under estimation, where loss seems to be an indication, seems like a serious matter and but still there is no normative language requirements on the reporting the loss. I wonder how useful this could be. If the reporting is that important to have a note in this specification then it is better to use normative langues to enforce it. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Zaheduzzaman Sarker's Discuss on draft-ietf-ipsecme-iptfs-17: (with DISCUSS and COMMENT)
Zaheduzzaman Sarker has entered the following ballot position for draft-ietf-ipsecme-iptfs-17: 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/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-ipsecme-iptfs/ -- DISCUSS: -- Thanks for working on this specification. I found this spec to be a mix of transport and non-transport related topics and had to think a bit more due to lack of rational behind choices made. I would like to discuss - why there is no normative text (MUST/MUST NOT) for non-congestion controlled mode over operation in this specification that prohibits the use of non-congestion controlled mode out side of controlled environment? I am also supporting Lars's discuss on 3.1 ECN support. -- COMMENT: -- The version of this specification changed quite frequently during the telechat review period, hence I am mentioning that I am reviewing the -17th version of this specification. I have following comments, which I believe will improve the specification if properly addressed - # Section 2.4: I would like to have rational behind the two mode of operations. what are the pros and cons and when would an implementer select one over another? if this is written somewhere else then having a point would be great benefit. # Section 2.4.1: I believe the assumption here is that the network is fully provisioned and no congestion related loss should occur hence here would not need to react to any loss. what would be source of the potential loss then? link failure only? if the loss is due to underestimation of bandwidth then 8084 need to be implemented as a last resort. It actually talks about circuit breakers in section 2.4.2.1 and somehow managed to say in addition to congestion control, the implementation that support non-congestion control mode should implement circuit breaker. This is where I am a bit lost, why is this written in section 2.4.2.1 and not in 2.4.1? is this the assumption that the implementation that have non-congestion control mode would not have congestion control mode? The failure correction due to the expected bandwidth under, where loss seems to be an indication, seems like a serious matter and but still there is no normative language requirements on the reporting the loss. I wonder how useful this could be. The last line actually makes me more confused. If ESP over TCP is in use then TCP would trigger the congestion control, thus this becomes a congestion controlled case and yes, you can then perhaps send out packets without thinking about congestion collapse. But then the assumption changes, then it becomes the case IP-TFS is expected to run over a congestion controlled transport. however, that is not the general assumption for the whole non-congestion controlled mode of operation. Here, I think we need to clarify a bit more on how to interpret the non-congestion controlled mode description. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
