Please, see inline as well (and I deleted parts where we are in agreement).
> Small touches like this are an improvement. Please skim through all the bare > SHOULDs (and SHOULD NOTs) to see if something similar should be said. I'll try to do my best. > >> 7th paragraph of 2.3.3 fails to parse at "by inclusion one". > > Perhaps: > > > > OLD: > > A GM MAY also indicate the support for IPcomp by inclusion one or > > more the IPCOMP_SUPPORTED notifications along with the SAg payload. > > > > NEW: > > A GM MAY also indicate the support for IPcomp by inclusion one or > > more the IPCOMP_SUPPORTED notifications along with the SAg payload > > into the request. > > > > Is it better? > > Perhaps: > > A GM MAY also indicate support for IPcomp by including one or more of the > IPCOMP_SUPPORTED notifications notifications along with the SAg payload. OK. > I think calling it out for _reviewers_ (especially the IESG) would be > helpful. It's not > helpful for readers 10 years from now. If it were me, I'd put it in a "Note > to be > deleted" in the IANA considerations section or ask the shepherd to amend the > shepherd writeup with a short explanation. The point is to save all of those > people > the effort of figuring out why _some_ of the new values already have > codepoints > and others are still TBA. OK, "Note to be deleted" makes sense. Will do. Regards, Valery. _______________________________________________ Gen-art mailing list -- gen-art@ietf.org To unsubscribe send an email to gen-art-le...@ietf.org
