Subject: [regext] Genart telechat review of draft-ietf-regext-bundling-registration-11

From: Joel Halpern via Datatracker <[email-masked]>
Date: Thu, 10 Oct 2019 15:56:18 -0700

Reviewer: Joel Halpern
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-regext-bundling-registration-11
Reviewer: Joel Halpern
Review Date: 2019-10-10
IETF LC End Date: None
IESG Telechat date: 2019-10-17

Summary: This document is almost ready for publication as an RFC.

I have received no response to my earlier review.  Some of the items have been
addressed, but not all of them.

Major issues:
    This document clearly defines normative protocol behavior.  As such, it
    would seem to either be Experimental or Proposed Standard, but not
    Informational.

Minor issues:
    The document incorporates items from a name space
    "urn:ietf:params:xml:ns:epp:b-dn", referred to with the prefix "b-dn:". 
    The only explanation of this meaning is in the terminology section.  
    However, the description does not indicate what document defines this
    information.

Nits/editorial comments:
    I note and appreciate that my comments on the SHOULD usage in section 7.2
    has been addressed.

---

From: "Jiankang Yao" <[email-masked]>
Date: Tue, 15 Oct 2019 15:55:29 +0800 (GMT+08:00)

> -----原始邮件-----
> 发件人: "Joel Halpern via Datatracker" <[email-masked]>
> 发送时间: 2019-10-11 06:56:18 (星期五)
> 收件人: [email-masked]
> 抄送: [email-masked], [email-masked], [email-masked]
> 主题: [regext] Genart telechat review of draft-ietf-regext-bundling-registration-11
> 
> Reviewer: Joel Halpern

Dear Joel Halpern,

  Thanks a lot for your kind review.

>     would seem to either be Experimental or Proposed Standard, but not

Because the WG chair clarified this issue in the mailing list after your review, the WG decided that this document should go to informational. I thought you may be clear about it.
So I did not directly response to this issue. Sorry about it. Some information about this issue from one of the co-chairs:

https://mailarchive.ietf.org/arch/msg/regext/wPQdna8E6eHkF4co4XDxrNzHPls#
https://mailarchive.ietf.org/arch/msg/regext/PILROKSKupLTh6tdVuye5b6ou1k

>     However, the description does not indicate what document defines this

In section 10 "IANA Considerations", the XML namesapce and schema is defined. IANA will add a XML registry for this document at https://www.iana.org/assignments/xml-registry/xml-registry.xml.
IANA is  requested to assignment the two URIs. One is urn:ietf:params:xml:ns:epp:b-dn.
 So the XML information can be checked on this page.

I hope that the above information can answer your concerns.

Thanks a lot.

Jiankang Yao

> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 15 Oct 2019 08:10:18 -0400

Regarding the document status, neither of the emails you pointed to 
explains why the document is Informational.  I understand from that and 
other discussions that there is no desire to make this standards track. 
  As has been noted, publication of usages of protocol by small groups 
is normally handled by the Independent Stream.  This document has been 
processed by the working group.

It is very strange for a protocol document to be processed by a working 
group, be accepted as not needing experimental status, and not be 
published as a standards track document.  Reading teh dcouemtn, I see no 
reason for it not to be standards track.

If there is concern that there may be problems with the document, then 
Experimental status would be the normal way to handle this document. 
With an explanation of what the experiment is intended to represent.

If the working group feels there is a good reason for informational 
publication, that should be document somewhere.  It is currently not 
documented in either the document itself or the shepherd report.

The fact that proprietary extensions to EPP are allowed by the protocol 
and registries is irrelevant.  This document is an IETF working group 
product and therefore is not a proprietary extension.

With regard to the "b-dn:" elements of this document, I am now more 
concerned than I was.  I had thought those were a reference to some 
other document that clearly defined the syntax and semantics of those 
elements.  I now understand that the given prefix is used for the new 
elements defined in this document.  The structure that is used to 
describe the expected and permitted content of these elements is qutie 
confusing.  The actual definition is only in the "formal syntax" 
section.  The descriptions are scattered embedded in descriptions of the 
messages, expecting to user to determine the permitted and required 
behavior from informal descriptive text.  Yes, for those who already 
know how it works and what it needs, everything is hear.  For a new 
implementor it is very hard to follow.

Yours,
Joel

PS: Replies to my concerns on the regext list that did not copy any of 
the IETF list, the genart list, or my email address were not seen by me, 
and will not be seen by me if that is chosen again.

---

From: John C Klensin <[email-masked]>
Date: Tue, 15 Oct 2019 12:59:47 -0400

Joel,

Let me try one reason why this should not be Standards Track or,
if it should, it isn't ready.  It uses, and is dependent on,
terminology for which there is no consensus definition and that
is used to describe different things in the wild.  As I think I
suggested one of my earlier notes about this, it would be
possible to say "these terms mean whatever the registry says
they mean", explicitly anticipating that different registries
might use the extension for slightly different purposes.   While
not a problem for an Informational document whose purpose is to
inform the community about what some registries are doing and
perhaps not for an Experimental one, neither that option nor
ignoring the definitional issue are consistent with our
expectations that standards track documents will at least lay a
foundation for interoperability.   Even if it worked for each
registry that uses it taken separately, many of us have seen
situations in which companies with different definitions and
applicability for given named concepts merge and the
difficulties that result.   For a standards track document,
creating such a situation would be, at least, a "known defect"
that requires exploration and explanation in the document, text
that is not present.

More details on these terminology issues in my two comments on
the Secdir review on the 13th.

best,
   john

--On Tuesday, October 15, 2019 08:10 -0400 "Joel M. Halpern"
<[email-masked]> wrote:

> Regarding the document status, neither of the emails you
> pointed to explains why the document is Informational.  I
> understand from that and other discussions that there is no
> desire to make this standards track.   As has been noted,
> publication of usages of protocol by small groups is normally
> handled by the Independent Stream.  This document has been
> It is very strange for a protocol document to be processed by
> a working group, be accepted as not needing experimental
> status, and not be published as a standards track document.
> Reading teh dcouemtn, I see no reason for it not to be
> standards track.
> 
> If there is concern that there may be problems with the
> document, then Experimental status would be the normal way to
> handle this document. With an explanation of what the
> experiment is intended to represent.
> 
> If the working group feels there is a good reason for
> informational publication, that should be document somewhere.
> It is currently not documented in either the document itself
> or the shepherd report.
> 
> The fact that proprietary extensions to EPP are allowed by the
> protocol and registries is irrelevant.  This document is an
> IETF working group product and therefore is not a proprietary
> extension.
> 
> With regard to the "b-dn:" elements of this document, I am now
> more concerned than I was.  I had thought those were a
> reference to some other document that clearly defined the
> syntax and semantics of those elements.  I now understand that
> the given prefix is used for the new elements defined in this
> document.  The structure that is used to describe the expected
> and permitted content of these elements is qutie confusing.
> The actual definition is only in the "formal syntax" section.
> The descriptions are scattered embedded in descriptions of the
> messages, expecting to user to determine the permitted and
> required behavior from informal descriptive text.  Yes, for
> those who already know how it works and what it needs,
> everything is hear.  For a new implementor it is very hard to
> follow.

---

From: Joel Halpern Direct <[email-masked]>
Date: Tue, 15 Oct 2019 13:52:05 -0400

If we do not have agreement on what the meaning is for the relevant 
terms, then either
1) The document should not be an IETF consensus document (which even 
Informational publication is)
or
2) The document should be Experimental, indicating explicitly that there 
is ambiguity in the terms, and one of the points of the experiment would 
be to find out if that matters.

Yours,
Joel

---

From: John C Klensin <[email-masked]>
Date: Tue, 15 Oct 2019 14:03:14 -0400

Joel,

Agreed.  And that is more or less what my notes of two days ago
said.  I apparently went into too much detail about the terms
and the issues with them and the messages apparently got lost in
the noise.

best,
   john

--On Tuesday, October 15, 2019 13:52 -0400 Joel Halpern Direct
<[email-masked]> wrote:

> If we do not have agreement on what the meaning is for the
> relevant terms, then either
> 1) The document should not be an IETF consensus document
> (which even Informational publication is)
> or
> 2) The document should be Experimental, indicating explicitly
> that there is ambiguity in the terms, and one of the points of
> the experiment would be to find out if that matters.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 15 Oct 2019 14:19:12 -0400

> Informational publication is)

Just a point on this: it's not true.

We have a "consensus" flag in the datatracker, which triggers a
boilerplate change.  It's always set to "yes" for Standards Track or
BCP, but for Informational and Experimental it can be set either way.
If it's set to "no", the boilerplate says that the document does not
have IETF consensus.  It's possible that when we're done with this
document it could settle into that.

It's also possible that we might convince the regext working group to
stop processing this document and suggest to the authors to go to the
ISE.  I don't think we're there yet, and at the moment the working
group has consensus to publish it as a working group product

Barry

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 15 Oct 2019 14:27:06 -0400

Barry, I have a real problem with us producing a document with WG rough 
consensus, IESG approval, but not IETF rough consensus.

People have been complaining about various markings causing confusion 
about the status and meaning of documents.  This seems a MUCH worse case 
than anything I have seen.

The fact that the tooling allows it, and even presumably that IESG 
processes allow it, does not make it a good idea.

If I think about it too much, I end up unable to parse the notion of a 
document published on the IETF stream without IETF rough consensus.

Yours,
Joel

---

From: Barry Leiba <[email-masked]>
Date: Tue, 15 Oct 2019 14:33:38 -0400

> document published on the IETF stream without IETF rough consensus.

And yet they are there today and will continue to be.

b

---

From: Eric Gray <[email-masked]>
Date: Tue, 15 Oct 2019 18:39:51 +0000

I have to agree with Joel - but from a different angle.

The "normal process" seems to be that - once an ID is approved at the WG level by rough consensus - it goes to the IESG and then to the IETF as a whole.

If (for some reason) it does not gain rough consensus from the IETF as a whole (and this seems to be an extreme corner case), then it could be published as an individual RFC - but should be kicked back to the WG to make this decision.  

If it was then published as an individual (informational or experimental) RFC - that would be effectively because it first ceased to be a WG consensus draft.

This may not be obvious, but it makes more sense than assuming that the WG could cause the RFC editor to publish an ID as any kind of a WG consensus RFC without IETF concensus...

-----Original Message-----
From: Gen-art <[email-masked]> On Behalf Of Barry Leiba
Sent: Tuesday, October 15, 2019 2:34 PM
To: Joel M. Halpern <[email-masked]>
Cc: IETF discussion list <[email-masked]>; Jiankang Yao <[email-masked]>; draft-ietf-regext-bundling-registration.all <[email-masked]>; John C Klensin <[email-masked]>; General Area Review Team <[email-masked]>; regext <[email-masked]>
Subject: Re: [Gen-art] [regext] Genart telechat review of draft-ietf-regext-bundling-registration-11

b

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Barry Leiba <[email-masked]>
Date: Tue, 15 Oct 2019 14:46:14 -0400

> If (for some reason) it does not gain rough consensus from the IETF as a whole (and this
> seems to be an extreme corner case), then it could be published as an individual RFC - but
> should be kicked back to the WG to make this decision.

Oh, yes, absolutely that: at the first cut, it will have to be the
working group that decides where to go from here.

Barry

---

From: Eric Gray <[email-masked]>
Date: Tue, 15 Oct 2019 19:09:18 +0000

In that case, you are talking about a slightly different case - and one not nearly so hard to wrap my head around.

It would be rare for an ID to get that far before things went that far south, but it clearly could happen.

Usually, if the ID was a WG chartered item, I would imagine the WG would first try to resolve issues raised during the IETF last call.  Otherwise the WG could elect to drop it and the original authors might then go for publication as an individual RFC.

I know of at least a small number of Internet Drafts that have either failed to be adopted by a WG, or been dropped by a WG - and subsequently published as an individual RFC.

I cannot recall any that have gotten past WG consensus and IESG review that failed to achieve IETF last call consensus and were then kicked back all the way to the original authors.  But - like I said - it could happen...

-----Original Message-----
From: Barry Leiba <[email-masked]> 
Sent: Tuesday, October 15, 2019 2:46 PM
To: Eric Gray <[email-masked]>
Cc: Joel M. Halpern <[email-masked]>; IETF discussion list <[email-masked]>; Jiankang Yao <[email-masked]>; draft-ietf-regext-bundling-registration.all <[email-masked]>; John C Klensin <[email-masked]>; General Area Review Team <[email-masked]>; regext <[email-masked]>
Subject: Re: [Gen-art] [regext] Genart telechat review of draft-ietf-regext-bundling-registration-11
Importance: High

> If (for some reason) it does not gain rough consensus from the IETF as 
> a whole (and this seems to be an extreme corner case), then it could 
> be published as an individual RFC - but should be kicked back to the WG to make this decision.

Oh, yes, absolutely that: at the first cut, it will have to be the working group that decides where to go from here.

Barry