Hi Randy,
Thank you for the follow-up.
Assuming that changes will be made to Section 5.12 to address the following:
> > (2) Shouldn't the following (and similar text) be updated to
> precise that the behavior is per AF?
I consider all my comments are addressed. Thanks.
Cheers,
Med
> -----Message d'origine-----
> De : Randy Bush <randy@xxxxxxx>
> Envoyé : mercredi 1 juin 2022 19:54
> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@xxxxxxxxxx>
> Cc : Mohamed Boucadair via Datatracker <noreply@xxxxxxxx>; rtg-
> dir@xxxxxxxx; draft-ietf-sidrops-8210bis.all@xxxxxxxx; last-
> call@xxxxxxxx; sidrops@xxxxxxxx
> Objet : Re: [Last-Call] Rtgdir telechat review of draft-ietf-
> sidrops-8210bis-06
>
> hi mohamed,
>
> i really appreciate your continued work and patience.
>
> > * Section 5.1 (Fields of a PDU): This section does not list the
> fields
> > of the newly added ASPA PDU (e.g., AFI Flags, Customer
> Autonomous
> > System Number, Provider Autonomous System Numbers, Provider AS
> > Count).
>
> fixed. but i have become unhappy that field definitions are
> repeated in multiple places. this is a recipe for confusion and
> mistakes.
>
> > * Section 5.12
> >
> > (1)
> >
> > OLD:
> > Receipt of an ASPA PDU announcement
> > (announce/withdraw flag == 1) when the router already has an
> ASPA PDU
> > with the same Customer Autonomous System Number and the same
> Address
> > Family (see Flags field), replaces the previous one.^
> > ^^^^^^
> >
> > NEW:
> > Receipt of an ASPA PDU announcement
> > (announce/withdraw flag == 1) when the router already has an
> ASPA PDU
> > with the same Customer Autonomous System Number and the same
> Address
> > Family (see AFI Flags field), replaces the previous one.
> > ^^^^^^^^
>
> yup
>
> > (2) Shouldn't the following (and similar text) be updated to
> precise that the behavior is per AF?
> >
> > CURRENT:
> > The router should see at most one ASPA from a cache for a
> particular
> > Customer Autonomous System Number active at any time.
> >
> > ...
> >
> > For the ASPA PDU, the announce/withdraw Flag is set to 1 to
> indicate
> > either the announcement of a new ASPA record or a replacement
> for a
> > previously announced record with the same Customer Autonomous
> System
> > Number. The announce/withdraw flag set to 0 indicates
> removal of the
> > ASPA record in total. Here, only the customer AS of the ASPA
> record
> > MUST be provided, the Provider AS Count as well as the
> Provider AS
> > Numbers list MUST BE zero.
> >
> > (nit: s/MUST BE/MUST be)
>
> ok
>
> > * Section 6:
> >
> > OLD:
> > Recommended default: 3600 seconds (2 hours).
> >
> > NEW:
> > Recommended default: 3600 seconds (1 hour).
>
> sigh
>
> > (I noted that you are discussing reverting for the Expire
> Interval).
>
> reversion won, , i.e. same as 6810 8210, 7200
>
> > * Section 7:
> >
> > (1)
> >
> > I would add some text to be explicit how the content of the
> Arbitrary
> > Text field is used on the receiver side to decide whether/which
> > version to use for subsequent exchanges. Typically, the highest
> common
> > version will be picked. If no common version is supported, the
> router
> > will cease the connection.
>
> If a cache which supports version N receives a query from a
> router
> which specifies its highest supported version Q < N, the cache
> MUST
> downgrade to protocol version Q [RFC6810] or [RFC8210] or send
> a
> version 2 Error Report PDU with Error Code 4 ("Unsupported
> Protocol
> Version") and terminate the connection; in which case the
> Arbitrary
> Text field of the ERROR Report PDU MUST be a list of one octet
> binary
> integers indicating the version numbers the cache supports.
> The
> router MUST choose the highest mutally supported version. If
> there
> are none, the router MUST abort the session, sending a version
> 2
> Error Report PDU with Error Code 4 ("Unsupported Protocol
> Version").
>
> >> 1. The cache may terminate the connection, perhaps with a
> version 4
> >> Error Report PDU, Unsupported Protocol Version.
> >
> > I guess you meant "version 2 Error Report PDU with Error Code
> 4".
>
> sigh
>
> thanks again!
>
> randy
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
