|
Hi,
On 16/04/2025, 18:34, "Michael Richardson" <mcr+ietf@xxxxxxxxxxxx> wrote: Thank you for this review, and your nit edits. I will turn your nits into one or two pull requests so that we can be sure we got them right. They don't look controversial at first glance. That should be easy to do before the IESG telechat on this document. Yes, hopefully, and thanks. Your higher level comments seem more difficult to deal with :-( I'm not entirely sure how much change we can/should make to a document that is going towards Internet Standard. I've asked the authors to convene next week to discuss this. The implied MUSTs concern me most. Perhaps there is someone who could comment more about how important it is to keep text similar. I think there’s two main areas of concern.
One is the use of MUST in some places and not in others, for the same context, e.g., “the client MUST insert foo” vs “the client inserts foo”. That happens inconsistently e.g. in Section 18. The other is the inconsistency in what’s said in Sections 16 and 18. I’d suggest someone (an author) goes through them both and checks in detail. One way to simplify it would be to just remove section 16,
much like the last Appendix where there might (but I didn’t check) also be inconsistencies. But that validation information being spelled out from the spec in Section 18 is useful. It’s also clear that the spec has evolved over time so the document has a somewhat “patchwork” feel to it. The way Reconfigure authentication is introduced (or rather isn’t) and then very ambiguous up until
it’s spelled out in Section 18 is a good example. So it depends if you, or the IESG, care about that. The other points in my review I made because they seemed odd to me, or confusing. If you’ve been working to that spec since it was 3315 I suspect you wouldn’t feel that way.
One reason we do not reference any new work (like RFFC9663) is that we might not have implementation experience there, and IS are supposed to be about what has actually been implemented. That’s a fair point and I’d overlooked the parallel push to IS. I would argue to include RFC 9663 on prefix per client as it will see wide use, but the self-registration RFC perhaps has a weaker case. For instance, has anyone actually implemented RFC9243 (the YANG model)? In some sense, this is outside of RFC8415bis in the sense that 8415bis deals with stuff that goes out the "southbound" interface. DHCP messages. While 9243 is about what goes out the "northbound" interface. True. But I thought it worth mentioning as it is a gap. Best wishes, Tim -- Michael Richardson <mcr+IETF@xxxxxxxxxxxx> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide |
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
