Alexey, As editor, I consider it much more important to get this document finished and out than to have extended arguments about references or philosophy. That said, I was trying to respond to Subramanian's note and issue list as the issues were stated there. Comments below from a slightly different and more personal perspective, leaving the Full Standard and current YAM requirements aside entirely...
--On Thursday, July 21, 2011 13:04 +0100 Alexey Melnikov <[email protected]> wrote: >... >> RFC 6186 is a Proposed Standard and was published in March >> 2011. I am not aware of any effort to move it to Draft >> Standard. As you mentioned, RFC 6186 does not update RFC >> 4409. A normative reference to RFC 6186 would be a >> downward reference. As there hasn't been consensus for such >> a change and based on the current status of RFC 6186, I >> recommend no action in the current document. > > I would love for RFC 6186 being mentioned (can I bribe you > guys :-)?). However I do agree that making it normative via > use of SHOULD is too strong. Maybe an Informative reference? > > <rant> > I do find all arguments around "we can't add this reference > because it is going to be a downref" to be quite counter > productive. Why are we being so process oriented when having a > downref might be the right thing to do? > </rant> What is said when a few of these things were being discussed earlier wasn't really about downrefs. I have a bias that, if we are going to direct someone from a Full Standard (or usually even a Draft Standard) to something in a way that encourages them to look at and use it, it should be relatively proven rather than something we might take a look at in a few years and say "never mind" (or worse, with the current 6to4 snit being an example). "Direct someone" is deliberately informal and vague. Certainly it applies to a normative requirement, so we agree about SHOULD. For an informative reference, my threshold for "relatively proven" is fairly low, but it is still higher than "no known defects" or "looks good in theory and on paper". That is precisely why I asked about implementation reports: if it can be shown that there is significant conforming implementation and non-trivial deployment of the 5451 or 6186 specs, then a note that essentially says "others have found these useful in conjunction with submission servers, you ought to consider them too" is appropriate, even if it doesn't get to a SHOULD-level requirement. On the other hand, to the extent to which there are few production implementations and deployments, it would be, IMO, better to think about the right timing for either updates to 5451 and 6186 or an Applicability Statement that would update both and 4409bis to specify that implementers of submission servers should look at those specs and MAY (or SHOULD) support them. > I think mentioning RFC 5451 falls into a similar category to > RFC 6186. Yeah. See above. Just my opinion. john _______________________________________________ yam mailing list [email protected] https://www.ietf.org/mailman/listinfo/yam
