Hi Alvaro, Thanks for the follow-up.
> I've looked at your replies and the diffs using the version - > 10. I still have a couple of comments in-line -- mostly about the > instructions to the designated experts. What is really key is that DEs motivate their decision and work with requesters to make a request successful. DEs usually consult with each other, but I don't need to we need to have this in the text. Below an updated DE text to reflect some of your comments. NEW: The policy for allocating new bits from this sub-registry is Specification Required (Section 4.6 of [RFC8126]). Review requests are evaluated on the advice of one or more designated experts. Criteria that should be applied by the designated experts include determining whether the proposed registration duplicates existing entries and whether the registration description is sufficiently detailed and fits the purpose of this registry. These criteria are considered in addition to those already provided in Section 4.6 of [RFC8126] (e.g., the proposed registration must be documented in a permanent and readily available public specification). The designated experts will either approve or deny the registration request, communicating this decision to IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Cheers, Med > -----Message d'origine----- > De : Alvaro Retana <[email protected]> > Envoyé : jeudi 12 janvier 2023 20:41 > À : Alberto Rodriguez-Natal (natal) <[email protected]>; > [email protected] > Cc : Vina Ermagan <[email protected]>; BOUCADAIR Mohamed INNOV/NET > <[email protected]>; Fabio Maino (fmaino) > <[email protected]>; [email protected]; Dino Farinacci > <[email protected]>; Luigi Iannone <[email protected]>; Albert > Cabellos <[email protected]>; Stefano Secci > <[email protected]>; Johnson Leong <[email protected]>; > JACQUENET Christian INNOV/NET <[email protected]>; > Sharon Barkai <[email protected]> > Objet : Re: AD Review of draft-ietf-lisp-pubsub-09 > > On November 6, 2022 at 5:32:47 AM, Alberto Rodriguez-Natal wrote: > > > Alberto: > > Hi! > > I've looked at your replies and the diffs using the version - > 10. I still have a couple of comments in-line -- mostly about the > instructions to the designated experts. > > Please move the text in §8 (Sample PubSub Deployment Experiences) > to an appendix and update the reference to rfc6830. > > I am starting the IETF Last Call. I know that you still have to > address Padma's comments -- you can treat them (and mine) as LC > comments. > > Thanks! > > Alvaro. > > > > ... > > > 144 4. Map-Request PubSub Additions > > > ... > > > [major] "MUST set the I bit to 1 and include its xTR-ID and > Site-ID" > > > > > What should the receiver do if the I bit is set but the ID > fields > > > are not included? > > > > [AR] As per the Alvaro/Dino discussion, we’re adding some text > along > > the lines of: “If the I-bit is set but the Site-ID and/or xTR-ID > are > > not included, a receiver can detect the error because after > processing > > that last EID-record, there are no bytes left from processing > the > > message. The receiver will log a malformed Map-Request and drop > the message.” > > Can we use normative language? s/will log...and drop/SHOULD > log...and MUST drop > > I'm also fine if you want to use "MUST" in both cases. > > > > ... > > > 296 6. Mapping Notification Publish Procedures ... > > > > > > [major] "If after a configurable timeout, the Map-Server has > not > > > received back the Map-Notify-Ack..." §5.7/rfc6833bis talks > about > > > exponentially backed-off retransmissions. You shouldn't change > the > > > behavior here. > > > > [AR] Please note that 9301 does not talk about trying to send a > > Map-Notify to a different ITR-RLOC, since in 9301 Map-Notifies > are not > > sent to ITR-RLOCs, hence the need to define this behavior here. > > Yes. I meant the part about a "configurable timeout" vs the > exponential back-off. > > > > ... > > > 482 10. IANA Considerations > ... > > > 515 The policy for allocating new bits from this sub-registry > is > > > 516 Specification Required (Section 4.6 of [RFC8126]). > > > > > > [major] "Specification Required" required the review of a > Designated > > > Expert. Please provide any specific instructions that the DEs > should > > > take into account when assigning values from this registry. > > > > ... > > NEW: > > > > The policy for allocating new bits from this sub-registry is > > Specification Required (Section 4.6 of [RFC8126]). It is > suggested > > that multiple designated experts be appointed for registry > change requests. > > The second sentence is not needed; the IESG always assigns a > couple of DEs. > > > > Criteria that should be applied by the designated experts > include > > determining whether the proposed registration duplicates > existing > > entries and whether the registration description is clear and > fits the > > purpose of this registry. These criteria are considered in > addition to > > those already provided in Section 4.6 of [RFC8126] (e.g., the > proposed > > registration must be documented in a permanent and readily > available public specification). > > Registration requests are evaluated within a three-week review > period > > on the advice of one or more designated experts. Within the > review > > period, the designated experts will either approve or deny the > > registration request, communicating this decision to IANA. > Denials > > should include an explanation and, if applicable, suggestions as > to > > how to make the request successful. > > How should the DE determine if "the registration description is > clear"? Is there any required information that the request should > have? Clarity is subjective and may change from one DE to the > next. > > I don't think that including a timeframe for evaluation ("three- > week review period") is a good idea. Not only delays can occur, > but IANA already has a practice of following up within a two-week > window -- so an exception would just be more work for them. > > If there is something that the DEs should be doing during the > evaluation time, please indicate so. Some registries ask the DEs > to at least ping the WG -- note that this doesn't mean that the > documentation has to be a WG draft (or even a draft at all), > unless that is what you want. Specification Required allows > anyone to request a codepoint without going through the IETF. _________________________________________________________________________________________________________________________ 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. _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
