Re: [yam] preliminary -- draft-ietf-yam-rfc1652bis-pre-evaluation

[Tony Hansen <[e-mail]>]

Dave CROCKER wrote:
> 
> 
> Tony Hansen wrote:
>> Dave, you removed the Date published section. Any particular reason?
> 
> Huh?  I'm looking at the third line of Section 2, of the file I sent, 
> and it says "Date Published".
> 
> What are you referring to?

Sorry -- I was looking at a diff, and for some reason it showed the Date 
Published line on one side and not on the other. My mistake.

>> You copied the text (trimmed down) from 2026. Do you think that should 
>> be a standard part of the template?
> 
> Definitely.
> 
> Individual recall of formal IETF rules and requirements tends to be 
> spotty, at best, and folks have a tendency to get inventive.  The text 
> is short, pragmatic and clear.  So let's make sure everybody sees it 
> regularly.

I agree that it's worthy of adding to the template.

>> Pre-Evaluation comments:
>>
>>
>> ===
>>     Non-Changes
>>     None, so far.
>>
>> I think it's reasonable to actually declare that there are no 
>> non-changes. The WG needs to discuss such a statement before the 
>> evaluation is passed to the IESG, so the "so far" seems disingenuous.
> 
> I put the 'so far' in there to make it obvious I was only reporting and 
> not taking a position.   I guess it was a form of inviting comment.

no problem.

>> ===
>>     Link to Draft Standard interoperability report,
>>     [[ No report appears to be on file with the IETF. /d ]]
>>
>> I'm not sure what to do here. This may be a tripping point for the IESG, 
> 
> My question is why?  An interoperability report is a requirement to go 
> to Draft, not for going to Full.
> 
> I don't think it's a problem to include one, if available, but I think 
> that any belief it's important entirely misses what this stage of 
> advancement is about.
> 
> If something has been massively deployed and use for a decade, what 
> possible, legitimate argument can there be that the formal report is 
> 'required'?
> 
> 
>> and we may need to provide an interop report for any RFCs that are 
>> missing one.
> 
> That, I believe, would be a strategic error, per above.
>
>> Questions to the WG: Do we put in some sort of simple statement like 
>> what Dave has in brackets, assume that one isn't needed, and see if 
>> the IESG barfs? Or do we offer up front to provide an interop report in 
> 
> +1.
> 
> 
>> cases where one is missing?  We could state that one will be provided 
>> along with the revised draft.
> 
> No.  IMO, it is not reasonable to have the IESG impose this kind of 
> extra work on us, given that the rules do not obviously point to it.

That's two with that view. (And, OMG, it's you and John! :-) )

Anyone else want to chime in?

> Have a range of different folks with operational email experience offer 
> expert statements that the thing is widely used and has been for a very 
> long time.  Done.

This seems worth providing as supporting evidence for the "Confidence" 
test. Providing such statements should possibly be part of the 
submission process for the final RFC, but doesn't need to be there for 
the pre-evaluation step.

	Tony Hansen
	[e-mail]