See on inline. 

> On Jul 21, 2025, at 4:47 AM, Roman Danyliw <[email protected]> wrote:
> 
> Hi Peter!
> 
> Thanks for the revised -08 draft.  
> 
> I need help understanding how this revising is responsive to my DISCUSS 
> feedback about the registry (now) in Section 12.3.
> 
> I see this block of new text:
> ==[ snip ]==
>   When a new constraint is defined, the rule associated with that
>   constraint MAY be inserted at any position.  Backwards compatibility
>   is guaranteed because nodes which don't support the new constraint
>   will not participate in an algorithm where the FAD specifies a
>   constraint they don't support.
> 
>   The relative ordering of existing rules MUST NOT be altered.  Doing
>   so has the potential to create backwards compatibility issues.
> 
>   Deletion of the rules MUST NOT be done.  Given that the rules are
>   only used conditionally based on the information carried in the
>   winning FAD, deletion of the rule is not necessary.
> 
>   Merging or repeating of the rules MUST NOT be done.
> 
>   There is no upper bound on the number of rules that the registry
>   supports.
> ==[ snip ]==
> 
> A few comments:
> 
> (a) What does this have to do with IANA?

The original flex algo document (RFC 9380). See excerpt inline: 


        Various links that include or exclude rules can be part of the Flex-
        Algorithm Definition. To refer to a particular bit within an Admin
        Group or Extended Admin Group, we use the term "color".

        Rules, in the order as specified below, MUST be used to prune links
        from the topology during the Flex-Algorithm computation.

 Since the original document, many flex algo extensions have been proposed and 
standardized. Maintaining an IANA registry allows specification across multiple 
documents progressing independently. 

Thanks,
Acee





> 
> (b) Is this guidance to designated expert on evaluating new registrations?  
> It doesn't say so.  If it is, what does it mean to "modify ordering of 
> existing rules"?  Is deleting "rules" removing their registration?
> 
> (c) RFC2119 shouldn't be used in the IANA considerations sections.  See 
> https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words//
> 
> Regards,
> Roman
> 
> 
> 
> -----Original Message-----
> From: Peter Psenak <[email protected]> 
> Sent: Monday, July 21, 2025 4:09 AM
> To: Mohamed Boucadair <[email protected]>; Roman Danyliw 
> <[email protected]>
> Cc: [email protected]; 
> [email protected]; [email protected]
> Subject: draft-ietf-lsr-igp-flex-algo-reverse-affinity-08
> 
> Warning: External Sender - do not click links or open attachments unless you 
> recognize the sender and know the content is safe.
> 
> 
> Mohamed, Roman,
> 
> I posted the new revision of the draft that should address your comments. 
> Please have a look and let me know if you have any more comments.
> 
> thanks,
> Peter

_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to