On Mon, Feb 22, 2021 at 8:23 AM Nick Hilliard <nick@xxxxxxxxxx> wrote: > > Tom, > > We're talking at cross-purposes here. This is a descriptive > Informational draft. Its aim is to describe a specific problem set > relating to an ipv6 protocol component. > Nick, I understand the purpose of the draft, however, IMO, for the problems that are described there is insufficient detail and scope to draw any meaningful conclusions or take away any new insights. When the draft mentions that routers might drop packets because packets are too long, then the obvious question is what exactly is too long. Since this draft is discussing real implementation and not theory, it seems like measuring the extent and determining the real operational parameters of the problems, like what a useful minimum length of header chains is, seems straightforward either by experimentation or simply polling router vendors to see what they support. Similarly for scope, of all the reasons listed in the draft what is the rate of occurrence? Is header chain length the biggest reason for drops or is it something else? Again that's something that seems eminimetly measurable and doesn't have to be left to the abstract which this draft seems content to do. Tom > Tom Herbert wrote on 22/02/2021 14:55: > > Yes, different routers do different things, but can you quantify what > > the most commonly deployed routers do? If we can do that then we could > > establish a better requirement for host stacks more than just "don't > > send IPv6 header chains that are too long". > > ... which proposes to turn the draft into a prescriptive draft, i.e. to > advise on what protocol implementers should do. > > We totally get the value proposition of what you're suggesting, but it > doesn't belong in this draft. Establishing workable limits is both > difficult and subjective, which is why our proposal is that it should be > in a future draft which would probably end up being a BCP. > > Nick -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
