On 2/4/2017 10:57 PM, Scharf, Michael (Nokia - DE) wrote: > [CCing TCPM for the part that matters to TCPM] > >> 4. citing drafts in support of future large SYN options: >> “Is there harm in doing this? E.g., is it bad practice to cite internet >> drafts (non-normatively, of course) in an RFC?” >> >> 4.a. Citing drafts does go against the current BCP, as I understand it. >> >> From https://tools.ietf.org/html/rfc2026#section-2.2, in a big star-box: >> “Under no circumstances should an Internet-Draft be referenced by any paper, >> report, or Request-for-Proposal, nor should a vendor claim compliance with an >> Internet-Draft.”
FWIW, Internet Drafts are cited when it is appropriate to refer non-normatively to a concept. Additionally, RFC20236 was published when Internet Drafts actually expired; that's a fantasy these days, as they are archived by the ISOC. >> There’s a partial exception right afterward, which I’m not sure how well it >> applies in this case: >> “ >> Note: It is acceptable to reference a standards-track specification >> that may reasonably be expected to be published as an RFC using the >> phrase "Work in Progress" without referencing an Internet-Draft. >> This may also be done in a standards track document itself as long >> as the specification in which the reference is made would stand as a >> complete and understandable document with or without the reference to >> the "Work in Progress". That would be exactly the exception that does apply here. If you want to talk about using extended option space, then it's better to cite a known discussion thereof and provide a summary than to speculate about it or give the impression that it is not an investigated topic. ... > While TCPM discusses large SYN options (for a long time already), all known > solutions have downsides. I do not believe that a non-TCPM document should > speculate on the feasibility solutions. > > Michael Agreed, but the point is that this doc probably SHOULD state that all known solutions have deployment difficulties. An option (such as this) that has SYN space limitations and does not address this issue is (IMO) giving a misleading impression about its own limitations. Joe _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc