Subject: Secdir telechat review of draft-ietf-regext-bundling-registration-11

From: Russ Housley via Datatracker <[email-masked]>
Date: Thu, 10 Oct 2019 08:02:57 -0700

Reviewer: Russ Housley
Review result: Has Issues

I reviewed this document as part of the Security Directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the Security Area
Directors.  Document authors, document editors, and WG chairs should
treat these comments just like any other IETF Last Call comments.

Document: draft-ietf-regext-bundling-registration-11
Reviewer: Russ Housley
Review Date: 2019-10-10
IETF LC End Date: 2019-03-15
IESG Telechat date: 2019-10-17

Summary: Has Issues

Major Concerns:

The Abstract ans Section 1 say: "This is a non-standard proprietary
extension." I understand that this is not a standards track document, so
the "non-standard" part makes sense.  However, what is the point of
publishing a "proprietary" extension as an RFC.  I would hope that
interoperable implementations is the goal of publication.

In Section 1, the use of "policy-wise" is unclear.  Is this registration
policy or something else?

Minor Concerns:

None.

Nits:

Section 1: s/label(LABEL)/label (LABEL)/
- s/(V-tld);/(V-tld)./

In addition, there are several places in the upper left corner of the
title page:
   Internet        Engineering     Task Force

---

From: "Jiankang Yao" <[email-masked]>
Date: Sun, 13 Oct 2019 21:58:40 +0800 (GMT+08:00)

> -----原始邮件-----
> 发件人: "Russ Housley via Datatracker" <[email-masked]>
> 发送时间: 2019-10-10 23:02:57 (星期四)
> 收件人: [email-masked]
> 抄送: [email-masked], [email-masked], [email-masked]
> 主题: Secdir telechat review of draft-ietf-regext-bundling-registration-11
> 
> Reviewer: Russ Housley

Dear Russ Housley.
  Thanks a lot for your kind review.

> the "non-standard" part makes sense. 

yes, the WG decided that this document is informational.

> However, what is the point of

If the registry follows this document, both registry and its all registrars should follow this document.
Yes, interoperable implementation is very important.

> policy or something else?

How about 
 Policy-wise bundling --->
 Bundling based on policy

> Section 1: s/label(LABEL)/label (LABEL)/

will update it.

Thanks a lot.

Jiankang Yao

---

From: Barry Leiba <[email-masked]>
Date: Sun, 13 Oct 2019 16:25:33 +0200

> interoperable implementations is the goal of publication.

I’m afraid this addition is my fault.  Perhaps “proprietary” is the wrong
word here: The point is that this is documenting an extension developed by
one registry and not in use by others, with the idea that if others want to
use it they can follow this to interoperable.  It’s rather like when we
documented Apple Bonjour as Informational.

Better word?

Barry

---

From: "Paul Hoffman" <[email-masked]>
Date: Sun, 13 Oct 2019 10:30:20 -0700

> documented Apple Bonjour as Informational.

Why have any word other than "non-standard"? It is *not* proprietary in 
that multiple vendors implement it and there appears to be no licensing 
requirement from the authors.

--Paul Hoffman

---

From: Barry Leiba <[email-masked]>
Date: Sun, 13 Oct 2019 20:11:03 +0200

Works for me: I had suggested “proprietary”, so I will now unsuggest it.
Authors, sorry about that: please remove that word in both places the next
time you make a revision.  Thanks.

Barry

---

From: John C Klensin <[email-masked]>
Date: Sun, 13 Oct 2019 14:39:59 -0400

--On Sunday, October 13, 2019 16:25 +0200 Barry Leiba
<[email-masked]> wrote:

>> The Abstract ans Section 1 say: "This is a non-standard
>> proprietary extension." I understand that this is not a
>> standards track document, so the "non-standard" part makes
>> sense.  However, what is the point of publishing a
>> "proprietary" extension as an RFC.  I would hope that
> I'm afraid this addition is my fault.  Perhaps
> "proprietary" is the wrong word here: The point is that
> this is documenting an extension developed by one registry and
> not in use by others, with the idea that if others want to use
> it they can follow this to interoperable.  It's rather like
> when we documented Apple Bonjour as Informational.
> 
> Better word?

Barry, 

Our traditional way of handling this sort of thing is to have
the title say "FooCompany's method of doing X" (presumably, in
this case, "CDNC Method for Domain Name Mapping Extension for
Strict Bundling Registration" (with or without the EPP
identification) and then identifying the companies or registries
that have implemented it in the Introduction.  Some of the
latter information is included in Section 12 on Implementation
Status but not only is that section not referenced from the
Introduction, but there is a note requesting that the RFC Editor
remove it.

Most such documents have been handled as Independent
Submissions, rather than by the IESG and the IESG has generally
insisted on such titles and introductory material as well as the
usual "this is not a standard..." boilerplate.   That list
specifically includes RFC 4290, an opinion piece on registration
procedures for IDNs that is referenced by this document, and
RFCs 3743 and 4713, which are the core JET and CDNC documents
respectively and which, while not referenced from this document,
appear to define and explain concepts essential to it.

If the Bonjour spec you are referring to is RFC 6886, while the
title does not reflect that status, the Abstract does indicate
its status and it was also handled as an Independent Submission.

Noting that there is a presumption of IESG Consensus for
anything published in the IETF Stream (even Informational
pieces), I suggest that if this is a non-standard, but
compatible, extension that is expected to be published in the
IETF Stream, the title should be adjusted to show the status as
above, the implementation status should be retained, and,
although it is unusual, an explicit statement should be included
that others are free to implement and use this extension without
any special arrangements with the authors or their
organizations.   

Or toss it over the wall to the ISE with an explicit note
indicating that there has been BOF, WG, and mailing list
discussions (possibly by including the Shepherd's report), that
the WG is in favor of this being published, waiving further RFC
5742, and urging expedited handling.  That would allow a quick
review through the ISE and associated processes, which are much
more familiar with this type of document than the IETF Stream
his historically been.

Technical comment:  While this protocol extension appears to be
applicable only to "strict bundling" and calls that term out in
the title, the term is, AFAICT, not ever defined in a rigorous
way.  The Introduction says "...strict bundling, which requires
all bundled names to share many same attributes".  Ignoring the
inconvenient English, "many same" is not a definition without
either a list of attributes or quantification like "at least
five of the following list".   When we get to Section 5, the
specification isn't talking about "strict bundling" any more,
but, even then, says "should share some parameter or attributes
associated with domain names", an even weaker and m0re vague
requirement.  So readers of this document who are considering
implementing the extension is not able to determine whether it
is applicable to their needs (at least in the absence of
discussions with the designers).  If "strict bundling" is really
whatever a particular registry says it is, that should be
explicit in the text.
    
    best,
     john

p.s. While I appreciate the acknowledgment which is possibly due
to my contributions to related work, I generally do not follow
EPP work (for reasons of which several of those copied on this
note are aware) and do not remember looking at this document, at
least in its present form, before it was called to my attention
by this correspondence.  On the other hand, perhaps the authors
could anticipate the future and proactively acknowledged my
comments above :-)

---

From: John C Klensin <[email-masked]>
Date: Sun, 13 Oct 2019 15:24:45 -0400

Sorry... Addendum to the technical comment quoted below:

The document uses the term "variant" extensively, but does not
define it either.  That term seems essential to what is going on
in this document.  It des not appear in RFC 8499 (which is not
cited in any event).  The term was introduced into the IETF and
DNS vocabulary by the JET Guidelines (RFC 3743) but the term
there, as called out in both the text and the IESG Note, is used
for language-based preferences and relationships.  In most of
the DNS registry and registrar communities, and in the ICANN
Variant Information Project that spawned the efforts that, in
turn, led to RFCs 7940 and 8228, the term is primarily used to
describe the potential for visual confusion among characters or
strings.  The document should be clear about whether one
definition, the other, or both are intended.   Again, if it is
not, it is not possible for readers to objectively determine
whether the specification is applicable to their needs.

thanks,
   john

--On Sunday, October 13, 2019 14:39 -0400 John C Klensin
<[email-masked]> wrote:

>...
> discussions with the designers).  If "strict bundling" is
> really whatever a particular registry says it is, that should
> be explicit in the text.
>...