Re: [bmwg] Zaheduzzaman Sarker's No Objection on draft-ietf-bmwg-ngfw-performance-13: (with COMMENT)

[Zaheduzzaman Sarker <[e-mail]>]

Thats a best case scenario and a fine request only. If you have immediate responses then will be great to respond as quickly as possible but does not need to resolve all the comments before the Telechat.

//Zahed

> On 3 Feb 2022, at 15:54, [e-mail] wrote:
> 
> We were asked to respond to any and all comments as quickly as possible so our AD would be able to speak to comments/objections knowledgeably. This request made total sense. 
>  
> Brian
>  
> From: Zaheduzzaman Sarker <[e-mail]> 
> Sent: Thursday, February 3, 2022 9:53 AM
> To: Carsten Rossenhoevel <[e-mail]>
> Cc: [e-mail]; The IESG <[e-mail]>; [e-mail]; [e-mail]
> Subject: Re: [bmwg] Zaheduzzaman Sarker's No Objection on draft-ietf-bmwg-ngfw-performance-13: (with COMMENT)
>  
> Hi Carsten,
>  
> I think you already got the information about the process and link to attend the Telechat in conversation with other ADs. Anyway adding the link to the process https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions <https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions> 
>  
> No, it is not expected that you need to respond within minutes just before the Telechat. 
>  
> Take your time and let me know if you need further help on this matter.
>  
> BR
> Zahed
> 
> 
>> On 3 Feb 2022, at 14:37, Carsten Rossenhoevel <[e-mail] <mailto:[e-mail]>> wrote:
>>  
>> Dear Zaheduzzaman,
>> 
>> Thank you for your comments.  I am getting a bit confused by this process - is it really expected that AD/IESG reviewers post their major comments hours before a decision is going to be made, and the authors have to try and rush responding within minutes?  I apologize that I am unfamiliar with this process.  In other SDOs where I am active, there are typically well-defined, reasonable deadlines and review/response intervals.  This does not delay standardization but improves its quality from my point of view.
>> 
>> We will respond to your other comments soon.
>> 
>> Best regards, Carsten
>> 
>> 
>> 
>> Am 03.02.2022 um 12:42 schrieb Zaheduzzaman Sarker via Datatracker:
>> 
>>> Zaheduzzaman Sarker has entered the following ballot position for
>>> draft-ietf-bmwg-ngfw-performance-13: 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/blog/handling-iesg-ballot-positions/ <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-bmwg-ngfw-performance/ <https://datatracker.ietf.org/doc/draft-ietf-bmwg-ngfw-performance/>
>>> 
>>> 
>>> 
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>> 
>>> Thanks for the efforts on this specification. I have been part of writing two
>>> testcase documents for real-time congestion control algorithms and understand
>>> getting things in a reasonable shape is hard.
>>> 
>>> I have similar observation as Murray and Eric when it comes to obsoleting the
>>> previous specification. Hence supporting their discusses.
>>> 
>>> Some more comments/questions below -
>>> 
>>>   * Section 5 : what is "packet loss latency" metric? where is it defined? how
>>>   do I measure?
>>> 
>>>   * Traffic profile is missing in all the benchmark test which is a MUST to
>>>   have. If this is intentional then a rational need to be added.
>>> 
>>>   * Section 7.3 and 7.7 : The HTTP throughput will look different not only
>>>   because of object size but also how often the request are sent. If the
>>>   requests are sent all at once the resulted throughput may look like a long
>>>   file download and if they are sparse then they will look small downloads in a
>>>   sparse timeline. Here, it is not clear to me what is the intention. Again the
>>>   traffic profile is missing and I am started to think that Section 7.1.3.3
>>>   might be part of Section 7.1.3.2.
>>> 
>>>   * Section 7.4 and 7.8 : I can have similar view as per my comment on Section
>>>   7.3. This is not clear to me that only object size matter here on the latency.
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> bmwg mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/bmwg <https://www.ietf.org/mailman/listinfo/bmwg>
>> -- 
>> Carsten Rossenhövel
>> Managing Director, EANTC AG (European Advanced Networking Test Center)
>> Salzufer 14, 10587 Berlin, Germany
>> office +49.30.3180595-21, fax [phone], mobile [phone]
>> [e-mail] <mailto:[e-mail]>, https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-5a55a80d61bce799&q=1&e=f53f20d7-64b0-45e4-bc0b-f671e58f8c68&u=https%3A%2F%2Fwww.eantc.de%2F <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-5a55a80d61bce799&q=1&e=f53f20d7-64b0-45e4-bc0b-f671e58f8c68&u=https%3A%2F%2Fwww.eantc.de%2F>
>> 
>> Place of Business/Sitz der Gesellschaft: Berlin, Germany
>> Chairman/Vorsitzender des Aufsichtsrats: Herbert Almus
>> Managing Directors/Vorstand: Carsten Rossenhövel, Gabriele Schrenk
>> Registered: HRB 73694, Amtsgericht Charlottenburg, Berlin, Germany
>> EU VAT No: DE812824025