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. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
