Hi Scott,
On Thu, Feb 18, 2021 at 04:51:52PM +0000, Hollenbeck, Scott wrote:
> > -----Original Message-----
> > From: Benjamin Kaduk via Datatracker <[email protected]>
> > Sent: Tuesday, February 16, 2021 7:51 PM
> > To: The IESG <[email protected]>
> > Cc: [email protected]; [email protected];
> > [email protected]; Jasdip Singh <[email protected]>; [email protected]
> > Subject: [EXTERNAL] Benjamin Kaduk's No Objection on draft-ietf-regext-
> > rfc7483bis-04: (with COMMENT)
> >
> > Caution: This email originated from outside the organization. Do not click
> > links
> > or open attachments unless you recognize the sender and know the content
> > is safe.
> >
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-regext-rfc7483bis-04: No Objection
> >
> > When responding, please keep the subject line intact and reply to all email
> > addresses included in the To and CC lines. (Feel free to cut this
> > introductory
> > paragraph, however.)
>
> [SAH] [snip]
>
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Should the errata against RFC 7483 in state "reported" be verified or
> > otherwise processed before this document gets approved?
>
> [SAH] I verified them and took care of the necessary fixed in 7483bis.
> Someone who has permissions to do so needs to update the Datatracker.
Indeed, that was mostly directed at Barry :)
> > My understanding (based on the draft name and shepherd writeup) is that
> > this document is intended to Obsolete: RFC 7483. If so, that should be
> > indicated in the header, abstract, and introduction, as (in my
> > understanding) the Gen-ART reviewer pointed out.
>
> [SAH] Yes, will fix.
>
> > Thank you for keeping the diff from RFC 7483 minimal -- that made things
> > very easy to read! (FWIW, I do consider converting all the links to the
> > "https"
> > scheme worth the churn; thank you for that as well.)
> >
> > Some of the examples have gone stale, though (or were inaccurate from the
> > start), particularly with respect to the cryptographic digests and
> > algorithms
> > used for DNSSEC. I do not think that we can in good conscience publish, in
> > 2021, an Internet Standard that shows RSA/MD5 signatures as an example!
> > (Specifics in the editorial section-by-section remarks.)
>
> [SAH] I'll look at those below.
>
> > Also, for Section 1.1, RFC 8174 has an updated BCP 14 boilerplate text to
> > use.
>
> [SAH] Will fix.
>
> > It's probably worth making a pass through the examples to check for cases
> > where the handle "XXXX" is being used for distinct entities within a single
> > example (as that's not really self-consistent).
>
> [SAH] I *think* I got all that straight when WG reviewers made the same
> comment some time ago.
I was pretty sure that I had seen at least one go by when I made this note
... perhaps Figure 23, that uses XXXX as the handle for Joe User's entity
and also for the containing domain? Figure 24 has a lot of "XXXX"s as
well, looking now (but not getting any further than there).
> > It may be worth noting in the security considerations that, while these RDAP
> > responses allow for retrieval of DNSSEC (key) related information,
> > (AFAICT) the RRSIG DS from the parent zone is not conveyed alongisde it.
> > This means that the DNSSEC keys retrieved by RDAP are disconnected from
> > their containing PKI, and as such are not generally expected to be trusted
> > without additional information. In particular, just the HTTPS channel
> > protecting the RDAP connection is not expected to be authorized to certify
> > the validity of the DNSSEC keys.
>
> [SAH] This is true, and it may be useful to add some additional text to make
> it clear. I'll see what I can do.
Thanks.
> > The rest of my remarks are basically editorial or nit level, and I don't
> > expect
> > specific responses to them.
> >
> > Section 3
> >
> > Contact information is defined using jCards as described in
> > [RFC7095]. The "fn" member is required and MUST NOT be null
> > according to [RFC6350], where an empty "fn" member MAY be used when
> > the contact name does not exist or is redacted.
> >
> > (editorial) The way the last sentence is written suggests that [use of empty
> > "fn" when the name does not exist or is redacted] is a behavior specified in
> > RFC 6350, but based on text searches in RFC 6350 I suspect that this
> > statement is actually a clarification new to this document about how the
> > jCard format is being used.
>
> [SAH] I'm going to adopt the fix suggested by Roman.
That looks good; I guess I missed Roman's note when I was submitting my own
ballot.
> > Section 4.1
> >
> > Going from 7483 to this document we now say that "rdapConformance"
> > MUST appear in the topmost JSON object of a response (vs "appears only" in
> > it). Is the intent to forbid "rdapConformance" from appearing anywhere else
> > in addition to the topmost JSON object? If so, the current text seems
> > insufficient to me.
>
> [SAH] Correct, it shouldn't appear anywhere else. "MUST appear in the topmost
> JSON object " is a requirement for both presence and location. "appears only"
> seems to leave some wiggle room in whether it needs to be present. Can you
> suggest a re-wording if it's not clear?
I think we'd have to make a separate requirement in order for it to be
clear, a la "MUST appear in the topmost JSON object of a response and MUST
NOT appear anywhere else".
> > Section 4.2
> >
> > The following is an example of the link structure:
> >
> > {
> > "value" : "https://secure-
> > web.cisco.com/1La4d1rUpkdc92phDKa17sS991fnDuBO3-
> > WlVJA0xMmd_qEBBMSmmELpoLRKNGUY-
> > imAXRq9_AvdWQjlzWt3luV4LFt9WxmMVg2mZGwUVWWomY2hbsjwIgvnJh
> > _20H8RJpsOqAxMFgG5D1BvBCuDa1EbDK3AoI3gWm88UiAWhMRm-
> > 4MZ5k8k8yj3CK1Aa0XktWyKGVeudlOYWfzklhIgtAVm95YyDba8426iSBJGe5Ip
> > 7bKEcZtk66HHMDVtZhWAi/https%3A%2F%2Fexample.com%2Fcontext_uri",
> > "rel" : "self",
> > "href" : "https://secure-web.cisco.com/1-
> > D4mH9SAtoE0W_T2b1RTQj6AyDwBgtdEBBe7JI5e-3C9uje37wTNu2-Q-
> > IBrYmxigaIv2kOotFrlQQH7b2qdlzhDnKOQeNOg97C4BkoPxOQ52LQDnCfdCeZ
> > yVxjyLp-
> > NT9eKwfByij0oHQ9Dnqcdw1Xv_ge8nPrp0r460RDfYZxjUfqN3d3ZeE_yi8qKCF
> > UKgM-
> > lQqK1eAO0GZviQ9_dXCp8WtqL7w68zlmsTI6s_t4vMpNUIjyFJLzrkvRXxqgQ/ht
> > tps%3A%2F%2Fexample.com%2Ftarget_uri",
> >
> > I am prone to confusing myself about RFC 8288 links, but it surprised me
> > that
> > "href" differed from "value" for a relation of type "self".
(Not sure if this one was skipped intentionally or not...I have pretty low
confidence that there's an issue, to be clear.)
> > The JSON name/values of "rel", "href", "hreflang", "title", "media",
> > and "type" correspond to values found in Section 3 of [RFC8288]. The
> > "value" JSON value is the context URI as described by [RFC8288]. The
> > "value", "rel" and "href" JSON values MUST be specified. [...]
> >
> > Looking just at the diff from RFC 7483 makes it seem that we gain a MUST-
> > level requirement for the "rel" value to be specified, which would not
> > normally be allowed in a transition to Internet Standard. However, it seems
> > that RFC 8288 itself requires the presence of "rel", so this is not in
> > practice a
> > new requirement, and thus safe.
>
> [SAH] That's my interpretation as well.
>
> > Section 4.5
> >
> > I think it's vCard that has a LANGUAGE property; in jCard that would be the
> > "language" key.
>
> [SAH] Agreed, that should be "vCard". Thanks for the catch.
>
> > Section 5.1
> >
> > [I did not attempt to validate that the jCards contained in any of the
> > examples conform to RFC 7095.]
> >
> > and names of organizations and individuals. Many of the types of
> > information that can be represented with jCard have no use in RDAP,
> > such as birthdays, anniversaries, and gender.
> >
> > (nit) I suggest s/no use/little or no use/, just on my instinct of avoiding
> > absolutes when not needed. ("Only a Sith deals in absolutes",
> > right?)
>
> [SAH] OK, makes sense.
>
> > The following is an elided example of an entity with embedded
> > entities.
> >
> > (nit) I'd suggest "abbreviated" or "condensed" instead of "elided", which as
> > written would seem to imply that the entire example is omitted.
> > This applies to more than one instance, but I will only mention it once.
>
> [SAH] I think I'll leave this one as-is. Elided does mean "To eliminate or
> leave out", which is what's going on here.
>
> > Section 5.3
> >
> > - idnTable -- the name of the Internationalized Domain Name (IDN)
> > table of codepoints, such as one listed with the IANA (see IDN
> > tables [IANA_IDNTABLES]).
> >
> > (nit) the definite article "the" in "the [IDN] table of codepoints"
> > implies that the context should indicate which one we are referring to
> > (perhaps the one used in the variant names?), but I am failing to tell from
> > context which table is being indicated.
>
> [SAH] I see your point. How about this: "The name of the Internationalized
> Domain Name (IDN) table that has been registered in the IANA Repository of
> IDN Practices [IANA_IDNTABLES]."?
I think that still leaves me uncertain how the table relates to the domain
object and the variant names thereof.
> > "keyTag": 12345,
> > "algorithm": 3,
> > "digestType": 1,
> > "digest": "49FD46E6C4B45C55D4AC"
> >
> > Could we maybe use SHA-256 for the example instead of the no-longer-safe-
> > for-general-use SHA-1 (so, digest type 2 instead of 1, and corresponding
> > digest length)? [Hmm, the existing SHA-1 example is
> > 20 hex digits, which is only 80 bits, not the full 160-bit SHA-1 output...]
> > Likewise for the signature algorithm (algorithm 3 is DSA/SHA-1, and there
> > are
> > lots of stronger alternatives listed at
> > https://secure-
> > web.cisco.com/1I8Di5U8y3NTUQw9mWzM4wGSzTlafm8s8sYb-
> > SwOMAkssj9r5pszzi1Zs5Ygzl0D1Sxx91nPpgnsoDjiB2VXMAoYIZZ82y2Mz1s3W
> > CPr3vOuK0Np5p1XQajn3FkaGC5QH4shVzJOhnXe06ta3H9wOgSA571FTY-
> > MXVDpk1O7iymHeaMwMphD3nOyxr1yZ1GTgu01Na1ljPIpXHTmfyaBabu8fn3
> > axVeaEj7PFao8o6jTCClRIQwElbE6MmesdpaRd/https%3A%2F%2Fwww.iana.o
> > rg%2Fassignments%2Fdns-sec-alg-numbers%2Fdns-sec-alg-numbers.xhtml)
> >
> > "flags": 257,
> > "protocol": 3,
> > "algorithm": 1,
> > "publicKey": "AQPJ////4Q==",
> >
> > Similarly, the key data here indicates the algorithm 1, or RSA/MD5 which is
> > deprecated. (The public key is also a laughably small 40-bit modulus when
> > decoded. A nice strong Ed25519 key, algorithm 15, would not expand the
> > example unreasonably in my opinion.)
>
> [SAH] I'll see if can find a more modern example.
>
> > "eventAction" : "expiration",
> > "eventDate" : "2016-12-31T23:59:59Z",
> > "eventActor" : "[email protected]"
> >
> > (side note) Perhaps an expiration in the future is more useful as an
> > example,
> > though it is clearly not wrong to list the expiration event even when it is
> > in
> > the past.
>
> [SAH] I'd prefer to leave this one alone since it's just an example inherited
> from 7483.
>
> > Section 5.5
> >
> > The following is an example of a JSON object representing an autnum.
> >
> > {
> > "objectClassName" : "autnum",
> > "handle" : "XXXX-RIR",
> > "startAutnum" : 10,
> > "endAutnum" : 15,
> >
> > IIUC AS numbers 10 through 15 are assigned by ARIN, including AS 11 that is
> > assigned to Harvard University (last updated 2019-08-12) and appears to be
> > in
> > current use. Perhaps the reserved ASN 0 would make for a safer example?
>
> [SAH] Perhaps. I'll check with my ARIN colleagues.
>
> > [...]
> > "links" :
> > [
> > {
> > "value" : "https://example.net/autnum/xxxx";,
> > "rel" : "self",
> > "href" : "https://example.net/autnum/xxxx";,
> > "type" : "application/rdap+json"
> >
> > Hmm, my reading of 7482bis suggests that the bit after /autnum/ should be
> > an actual AS number, not a handle. But it doesn't seem to give much
> > guidance on how to represent a block of AS numbers as opposed to a single
> > one within a block...
>
> [SAH] The "xxxx" used here is just an attempt to mask an autnum, but if that
> seems to confusingly look like it's a handle I can use a different mask,
> perhaps "yyyy"?
If we're giving explicit values for "startAutnum" and "endAutnum", I would
have thought that we could just pick a distinguished value from that range
and use it instead of a placeholder. (But see also my remark about not
knowing how to represent a range in an autnum URL...)
> > * type -- a string containing an RIR-specific classification of the
> > autnum
> >
> > (nit) is this the RIR's classification of the number itself, or the
> > allocation/registration?
>
> [SAH] I'll check with my ARIN colleagues.
>
> > Section 10
> >
> > I think that sometimes we see "-bis" documents that just say "IANA has
> > updated the registrations made by RFCXXXX to refer to this document", but I
> > don't particularly mind repeating the registration information in the now-
> > primary reference document.
> >
> > Section 10.1
> >
> > Published specification: RFC 7483
> >
> > Presumably we want this updated to the rfc-to-be?
>
> [SAH] Correct.
>
> > Section 10.2.4
> >
> > Description: The entity object instance represents a third party
> > through which the registration was conducted (i.e. not the
> > registry or registrar).
> >
> > (nit/side-note) I am pretty sure the RFC Editor is going to add the comma
> > back after "i.e." (but expect that leaving it for them to do will cause the
> > right
> > thing to happen). Perhaps we should ask IANA and the RFC Editor to get on
> > the same page...
> >
> > Section 13.1
> >
> > The default text encoding for JSON responses in RDAP is UTF-8
> > [RFC3629], and all servers and clients MUST support UTF-8.
> >
> > (I note that UTF-8 preference is one of the things that changed from RFC
> > 7159 to RFC 8259, so this may be redundant now. I didn't think about it
> > very
> > hard and don't expect anyone else to, as there's no harm in leaving it
> > alone.)
> >
> > Section A.1
> >
> > The following is an elided example of a registrant with information
> > changed to reflect that of a third party.
> >
> > {
> > ...
> > "entities" :
> > [
> > {
> > "objectClassName" : "entity",
> > "handle" : "XXXX",
> > ...
> > "roles" : [ "registrant", "administrative" ],
> > "status" : [ "proxy", "private", "obscured" ]
> >
> > (editorial) it might be nice to show a little more, so that we can contrast
> > "Joe
> > User" with "Anonymizing Proxy Service" (or whatever).
> >
> > Section A.1
> >
> > ["email",
> > { "type":"work" },
> > "text", "[email protected]"
> >
> > I wonder if the 'example' TLD might be more apropos for this case (e.g.,
> > [email protected]). (The link might be altered
> > similarly as well.)
> >
> > Section D
> >
> > DNSSEC provides data integrity for DNS through the digital signing of
> > resource records. [...]
> >
> > It also provides source authenticity, which is equally important.
>
> [SAH] I'm inclined to leave the examples alone, but I can add "source
> authenticity".
Okay, that's your prerogative.
Thanks,
Ben
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
