On 5 Oct 2016, at 5:10, Patrik Fältström wrote:
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 <p...@frobbit.se> 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.
I somewhat agree with Patrick here. My take is that a lot of ICANN
documents will never be « formatted » as needed for protocol
referenced documents, since they just serve different purposes. They
will have a lot of additional stuff not relevant for technical protocol
and might not be organized for technical reference. One idea might be
to extract the technical stuff from ICANN documents and make it an IETF
document and then make it normative. A bit more work on IETF side but
parties involved have the incentive to do it and will probably result in
a better framework of technical documents.
Regards, Marc.
Patrik
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
