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.
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
