"Les Ginsberg (ginsberg)" <[email protected]> writes:
Chris - I am continuing to think on this - based both on Bruno's input and now your input. However, this would seem to potentially put the WG in the role of being asked to pass judgment on whether a given implementation's configuration options are conformant or not. This is not a role I want to play - nor is it a responsibility I think the WG should take on. I would be interested in your thoughts in this regard (with or without your WG chair hat on).
With chair hat on... Well, we do write standards, we don't directly "pass judgment" on an implementation conformance to those standards -- that's not our job. However, it is our job to write clear, non-ambiguous standards so that others can determine conformance. As far as mandating configuration in RFCs, we (the IETF) do do this.. here's a couple I found by searching SMTP REFC5321: Retries continue until the message is transmitted or the sender gives up; the give-up time generally needs to be at least 4-5 days. It MAY be appropriate to set a shorter maximum number of retries for non- delivery notifications and equivalent error messages than for standard messages. The parameters to the retry algorithm MUST be configurable. SIP RFC3261: 21.4.23 485 Ambiguous The Request-URI was ambiguous. The response MAY contain a listing of possible unambiguous addresses in Contact header fields. Revealing alternatives can infringe on privacy of the user or the organization. It MUST be possible to configure a server to respond with status 404 (Not Found) or to suppress the listing of possible choices for ambiguous Request-URIs. [as wg member] I find myself agreeing with Bruno, that either we should require the ability to disable advertisement of multi-part TLVs, or we could mandate that it only be used once required (i.e., the user has made some configuration that caused multi part TLVs to be needed). I'm being particular with that second option though. I don't think we have to mandate never using multi-part TLVs when the advertised TLV data would fit within a single TLV. It should be sufficient to mandate when this multi-tlv use is first used. For example, we could say that a multi-part TLVs will only be first originated when the data for a TLV exceeds its available space, but once originated the total advertised space used by the mutli-part TLVs does not need to continue to exceed a single TLVs available space (i.e., multi-part TLVs are not required to collapse back to a single TLV if they shrink in size). The operator needs some way to deploy newer router software that doesn't break their network when they have existing routers that do not support multi-part TLVs. I think we are capable of providing for this in our RFC. Thanks, Chris.
Thanx. Les-----Original Message----- From: Christian Hopps <[email protected]> Sent: Monday, September 2, 2024 9:06 AM To: [email protected] Cc: Christian Hopps <[email protected]>; Les Ginsberg (ginsberg) <[email protected]>; Yingzhen Qu <[email protected]>; lsr <[email protected]>; lsr-chairs <[email protected]> Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024) > On Sep 2, 2024, at 11:38, [email protected] wrote: > > It is not within the purview of an RFC to mandate that an implementation have a particular knob. > [Bruno] > • According to which document /rule? [as wg-member] Regardless of whether we choose to add this requirement, I'm pretty sure it's fine to mandate that something be configurable (e.g., disable/enable) in an RFC. I haven't done a search but I definitely have seen this in other documents. What this would be saying is that in order to claim support for RFCXXXX one must have the given configuration option. Thanks, Chris. [as wg-member]
signature.asc
Description: PGP signature
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
