Hi Les, 

> On Aug 31, 2023, at 4:39 PM, Les Ginsberg (ginsberg) <[email protected]> 
> wrote:
> 
> Acee -
>  From: Acee Lindem <[email protected]> 
> Sent: Thursday, August 31, 2023 10:33 AM
> To: Acee Lindem <[email protected]>
> Cc: lsr <[email protected]>; [email protected]
> Subject: Re: Working Group Last Call for "IS-IS Fast Flooding" - 
> draft-ietf-lsr-isis-fast-flooding-04
>  I support publication. 
> 
> I’ve done the shepherds review and have some editorial comments that I think 
> will improve the readability (attached). Some of these are definitely 
> subjective and optional. Others are obvious editorial comments (e.g., 
> correction of minimumLSPTransmission-Interval to not have a hyphen). 
> 
> I also have the following comments:
> 
>    1. In section 6.2.2.1, does the sending rate really increases as the Round 
> Trip Time (RTT) increases? This is counter-intuitive. It seems to me that the 
> rate would increase as the RTT decreases?
>    2. I notice you use “:=“ for assignment in the algorithm descriptions. Is 
> there a convention for this rather than just using “=“? Reminds me of 
> ALGOL-68 ;^)
> [LES:] I will let Bruno/Guillaume address the above
> 
>    3. The algorithms in section 6 are non-normative, yet there is some 
> normative language, e.g., MUST. Either the algorithm sub-sections need to 
> clearly delineated or if all of section 6 is non-normative, lowercase must be 
> used. 
> 
> [LES:] You want lower case – or do you want SHOULD ?
> There are instances of upper case SHOULD – but you did not comment on them.

When I saw these I thought that possibly only the subsections with the actual 
algorithms should be non-normative and the general flow/congestion  guidance 
should be normative. I’ll let the authors decide. Alvaro has reminded me 
several times that normative language can't be used in non-normative sections. 

Thanks,
Acee




> ??
>     Les
> 
> 
> Thanks,
> Acee
> 
> 
>  
> 
> 
> 
> 
> > On Jul 19, 2023, at 7:06 PM, Acee Lindem <[email protected]> wrote:
> > 
> > This begins three week LSR Working Group last call for the “IS-IS Fast 
> > Flooding”. Please express your support or objection prior to Friday, August 
> > 11th, 2023. The longer WG last call is to account for the IETF being next 
> > week. 
> > 
> > Thanks,
> > Acee


_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to