Hi, thanks for the review! I'll incorporate respective changes into -14.
On 2016-05-28, at 20:23, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote: > After diffing this document against RFC5405 I see that it really is an > incremental change that leaves the scope largely unchanged except for the > addition of multicast. So perhaps I am too late to question the scope of the > document. But since this *is* a bis, it might be worth considering whether > the scope could be focused by splitting some of the material off into a > different document(s). You're right that we inherited this from 5405. And I'm going to use that as the reason to push back on refactoring this ID into multiple ones this late in the process. It'll move us back to square one. It's also not come up in any of the many reviews this ID has gotten so far, or for 5405 itself. > (2) MINOR? - use of SHOULD > > I was struck by how much SHOULD is used in this document, and how > infrequently MUST is used. And while possible justifications for violating > SHOULD are sometimes provided, they often are not. In my experience there has > been a growing awareness that such vagueness is problematic, because many > implementers take it as free license to treat SHOULD as MAY, and just not do > it. This is guidelines BCP. For almost every guideline, there are valid reasons for an application to not follow the SHOULD in this document. But those are application-motivated reasons. This document can't really provide an exhaustive list of reasons on when it is OK and not OK to not follow a SHOULD. It is up to the applications specs that use this BCP to argue why the didn't follow one of our SHOULDs and why. > (IIUC, in a BCP the normative language is relative to best practice. So if > MUST is written and you don't do it then you aren't following best practice. > But if SHOULD is written without qualification, and you don't follow it then > you can probably claim that you are still following the best practice as > documented by the document.) And that is exactly what is intended. It is OK for applications - after reflection - to not follow one of our SHOULDs, if they can document a valid reason. > (5) NITs - unlinked references > > I found a number of cases where, in the html format, references are not > hyperlinked: > > [RFC5405] section 1 > [RFC4342] section 3 > [RFC6679] section 3.1.7 > [RFC1981] section 3.2 > [RFC6935] section 3.4.1 Those seem to be due to bugs in rfcmarkup. Lars
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
