On 5 Oct 2016, at 10:56, Alexey Melnikov wrote: > To followup on my previous reply: > > On 5 Oct 2016, at 08:16, Patrik Fältström <[email protected]> wrote: > >>> Based on your comments, it appears that this >>> I-D should be an informational document, and I have no objections for making >>> this I-D an informational document. This I-D is included in >>> draft-ietf-regext-launchphase (standards track) as a normative reference, >>> and is >>> my understanding that is possible to include an informational RFC as a >>> normative reference in an standards track document, @chairs please correct >>> me if >>> I am wrong. >> >> When I was an AD, that was not possible. And that is the whole point with >> Standards Track. To implement it you do only rely on documents that have a >> well known change process that is accepted and documented. Some >> organizations (IETF and ISO etc) do have agreements how to make normative >> references between each others documents. I do not think IETF and ICANN do. > > Patrick, > Do you think IESG should discuss referencing ICANN documents and come to some > kind of consensus?
My immediate reaction is "yes", as last call processes might be messy if we are unlucky. So IESG might have to prepare themselves (via TEG?) on mapping the ICANN PDP's into IETF PDPs. And come with indications on what is needed on the ICANN side for a normative reference. And no, personally I have no idea. >> My view, my personal view, is that the documents you reference normatively >> are not stable enough to be normative references in an IETF Standards Track >> Document (even a few hops away). The process for changing them in ICANN is >> not even near as predictive as the IETF Standards Track Process. > > And that might be a good enough reason while a normative document to ICANN > document might not be appropriate. I am, as some people on this list might know, an individual that is conservative and careful regarding normative references. Think about when a document on IETF side move forward on standards track, and we have a move from Proposed standard because two independent implementation exists that are interoperable. If then some normative reference change, what is to happen? I.e. there is a reason why a document on one level on Standards Track can not have a normative reference to a different Standards Track document on a lower level. And implications like that must be discussed, I think, before normative references are made from Standards Track Documents in IETF to documents produced in the ICANN PDPs. Patrik
signature.asc
Description: OpenPGP digital signature
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
