Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-attrleaf-fix-00.txt

My current thought is that the draft's language should direct a MUST for 'published' specifications. This would implicitly leave private, developmental efforts free to experiment without registration. Sure. Like I said, private arrangements don't count. I suggest, instead, that the working

Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-attrleaf-fix-00.txt

On 5/12/2018 1:01 PM, John R Levine wrote: The best I can guess is that there is an underlying assumption that normative language only applies to formally published specifications, but there's nothing in the current draft language to support that. No, it's that standards are about

Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-attrleaf-fix-00.txt

I don't want to rathole on MUST vs. SHOULD because the more I think about it the less I understand the difference. Consider the long history of email header fields that weren't registered but which interoperated quite nicely... Sort of. Everything interoperated fine in the sense that we

Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-attrleaf-fix-00.txt

On 5/11/2018 7:41 PM, John Levine wrote: I'd change all of the SHOULD to MUST, as in you have to do this if you want to interoperate. The working group should consider the choice of normative level, but where I landed is that a MUST is not needed and actually could be

Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-attrleaf-fix-00.txt

In article you write: >For working group review, I suggest folk consider the draft in terms of >3, basic concerns: > >Clarity: Does the draft adequately explain its purpose and > adequately explain its approach for satisfying

Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-attrleaf-fix-00.txt

On 5/11/2018 3:28 PM, Warren Kumari wrote: I'm going to be rude and not answer any of the below questions -- instead, I'm going to mention "SMTP MTA Strict Transport Security (MTA-STS) draft-ietf-uta-mta-sts" (which completed IETF LC, etc a while back). This document uses the label _mta_sts:

Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-attrleaf-fix-00.txt

On Fri, May 11, 2018 at 3:57 PM Dave Crocker wrote: > Folks, > > G'day. > The latest wg's agreed approach for the Attrleaf specification is to > have a clean-sheet document that does /not/ reflect the problematic > history, with a companion specification that does. That is,

[DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-attrleaf-fix-00.txt

Folks, G'day. The latest wg's agreed approach for the Attrleaf specification is to have a clean-sheet document that does /not/ reflect the problematic history, with a companion specification that does. That is, the first document is to specify the registry as if there were no history of