> -----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.
> 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.
> 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.
> 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.
> 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?
> 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".
>
> 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]."?
> "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"?
> * 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".
Scott
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
