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.
On 10/15/2019 3:55 AM, Jiankang Yao wrote:
-----原始邮件-----
发件人: "Joel Halpern via Datatracker" <noreply@xxxxxxxx>
发送时间: 2019-10-11 06:56:18 (星期五)
收件人: gen-art@xxxxxxxx
抄送: draft-ietf-regext-bundling-registration.all@xxxxxxxx, ietf@xxxxxxxx, regext@xxxxxxxx
主题: [regext] Genart telechat review of draft-ietf-regext-bundling-registration-11
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
Dear Joel Halpern,
Thanks a lot for your kind review.
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.
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
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.
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
Nits/editorial comments:
I note and appreciate that my comments on the SHOULD usage in section 7.2
has been addressed.
_______________________________________________
regext mailing list
regext@xxxxxxxx
https://www.ietf.org/mailman/listinfo/regext
