Adrian Farrel via Datatracker <[email protected]> wrote:
    > Section 5

    > You say:

    >    This document assumes that a single transaction for all of the IA
    > options required on an interface is used, as recommended in Section
    > 18.1 of [I-D.ietf-dhc-rfc8415bis].

    > Section 18.1 of [I-D.ietf-dhc-rfc8415bis] says:

    >    This document assumes that a client SHOULD use a single transaction
    > for all of the IA options required on an interface

    > I asked the authors of draft-ietf-dhc-rfc8415bis to clarify this for
    > me, and it appears that the intention here is to guide implementers on
    > the wise course of action, but there is no implication for interop or
    > bits on the wire.

    > Anyway, notwithstanding the use of "SHOULD", it is perfectly possible
    > and legal for multiple transactions to be used. That means that your
    > draft needs to support multiple transactions even if it is suboptimal
    > or self-harm for an implementation.

    > What do you think? Is this support automatic in your spec? If so, I
    > think you might clarify this text as (note lower case usage):

    >    This document recommends the use of a single transaction for all of
    > the IA options required on an interface is used, as recommended in
    > Section 18.1 of [I-D.ietf-dhc-rfc8415bis]. This simplifies the client
    > implementation and reduces the potential number of transactions
    > required. However, a client may use multiple transactions and the
    > processes described in this document will funciton correctly.

Your text is an improvement, but I think that no words would be better.

As I wrote in my reply, I am not convinced that there are actually ever more
than one transaction to do.
If there is, then I'd like it if the srv6-locator document was explicit
about what those multiple transactions *are*

--
Michael Richardson <[email protected]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide




Attachment: signature.asc
Description: PGP signature

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

Reply via email to