Re: [IPsec] Zaheduzzaman Sarker's Discuss on draft-ietf-ipsecme-iptfs-17: (with DISCUSS and COMMENT)

2022-09-08 Thread Zaheduzzaman Sarker 
Hi, I have now cleared my discuss. Thanks for addressing them. However, I was hoping the following comments would get addressed too, as I think they would improve the spec. # 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.  //Zahed On 2022-08-29, 14:53, "iesg"  wrote: Hi Zahed, please see inline... Zaheduzzaman Sarker  writes: > -Original Message-> From: iesg  On Behalf Of Christian Hopps> Sent: den 25 augusti 2022 15:43> To: Zaheduzzaman Sarker > Cc: The IESG ; draft-ietf-ipsecme-ip...@ietf.org; ipsecme-cha...@ietf.org; ipsec@ietf.org; kivi...@iki.fi> Subject: Re: Zaheduzzaman Sarker's Discuss on draft-ietf-ipsecme-iptfs-17: (with DISCUSS and COMMENT)> > > Hi Zaheduzzaman,> > [inline]> > Zaheduzzaman Sarker via Datatracker  writes: >> -->> DISCUSS:>> --... >> I am also supporting Lars's discuss on 3.1 ECN support.> > This 2nd paragraph was added to satisfy this DISCUSS, please see the latest version:> > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-iptfs-17#section-3.1> > I believe we will discussing those proposals, if they are good enough. Lets continue the discussion in Lars's discuss thread. Lars has already replied in the affirmative: >> We have a couple more ADs with ECN as a DISCUSS:>> >> - Lars - You wanted us to be explicit about what to do with ECN field based on RFC6040. The propsed text above satisfies this requirement I beleive. Agreed?> > yes, possibly with the addition Martin later suggested ("unless all inner packets have the same marking").> > Thanks,> Lars> > //Zahed 

smime.p7s
Description: S/MIME cryptographic signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Zaheduzzaman Sarker's Discuss on draft-ietf-ipsecme-iptfs-17: (with DISCUSS and COMMENT)

2022-08-29 Thread Christian Hopps 


Hi Zahed,

please see inline...

Zaheduzzaman Sarker  writes:


-Original Message-
From: iesg  On Behalf Of Christian Hopps
Sent: den 25 augusti 2022 15:43
To: Zaheduzzaman Sarker 
Cc: The IESG ; draft-ietf-ipsecme-ip...@ietf.org; 
ipsecme-cha...@ietf.org; ipsec@ietf.org; kivi...@iki.fi
Subject: Re: Zaheduzzaman Sarker's Discuss on draft-ietf-ipsecme-iptfs-17: 
(with DISCUSS and COMMENT)


Hi Zaheduzzaman,

[inline]

Zaheduzzaman Sarker via Datatracker  writes:



--
DISCUSS:
--

...


I am also supporting Lars's discuss on 3.1 ECN support.


This 2nd paragraph was added to satisfy this DISCUSS, please see the latest 
version:

https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-iptfs-17#section-3.1

I believe we will discussing those proposals, if they are good enough. Lets 
continue the discussion in Lars's discuss thread.


Lars has already replied in the affirmative:


We have a couple more ADs with ECN as a DISCUSS:

- Lars - You wanted us to be explicit about what to do with ECN field based on 
RFC6040. The propsed text above satisfies this requirement I beleive. Agreed?


yes, possibly with the addition Martin later suggested ("unless all inner packets 
have the same marking").

Thanks,
Lars







//Zahed




signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Zaheduzzaman Sarker's Discuss on draft-ietf-ipsecme-iptfs-17: (with DISCUSS and COMMENT)

2022-08-29 Thread Zaheduzzaman Sarker 



-Original Message-
From: iesg  On Behalf Of Christian Hopps
Sent: den 25 augusti 2022 15:43
To: Zaheduzzaman Sarker 
Cc: The IESG ; draft-ietf-ipsecme-ip...@ietf.org; 
ipsecme-cha...@ietf.org; ipsec@ietf.org; kivi...@iki.fi
Subject: Re: Zaheduzzaman Sarker's Discuss on draft-ietf-ipsecme-iptfs-17: 
(with DISCUSS and COMMENT)


Hi Zaheduzzaman,

[inline]

Zaheduzzaman Sarker via Datatracker  writes:

> 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-posi
> tions/ 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?

Indeed, the suggested text we offered to add was:

  "This MUST NOT be used when full admin control over the network cannot be 
assured."

Ok, good.

> I am also supporting Lars's discuss on 3.1 ECN support.

This 2nd paragraph was added to satisfy this DISCUSS, please see the latest 
version:

https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-iptfs-17#section-3.1


I believe we will discussing those proposals, if they are good enough. Lets 
continue the discussion in Lars's discuss thread.


//Zahed

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Zaheduzzaman Sarker's Discuss on draft-ietf-ipsecme-iptfs-17: (with DISCUSS and COMMENT)

2022-08-25 Thread Christian Hopps 


Hi Zaheduzzaman,

[inline]

Zaheduzzaman Sarker via Datatracker  writes:


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?


Indeed, the suggested text we offered to add was:

 "This MUST NOT be used when full admin control over the network cannot be 
assured."


I am also supporting Lars's discuss on 3.1 ECN support.


This 2nd paragraph was added to satisfy this DISCUSS, please see the latest 
version:

https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-iptfs-17#section-3.1

Thanks,
Chris.


signature.asc
Description: PGP signature
___
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)

2022-08-25 Thread Zaheduzzaman Sarker via Datatracker 
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