> -----Original Message----- > From: Valery Smyslov <valery@xxxxxxxxxxx> > Sent: Wednesday, August 30, 2023 4:23 AM > To: Hollenbeck, Scott <shollenbeck@xxxxxxxxxxxx>; art@xxxxxxxx > Cc: draft-ietf-regext-rdap-openid.all@xxxxxxxx; last-call@xxxxxxxx; > regext@xxxxxxxx > Subject: [EXTERNAL] RE: Artart last call review of draft-ietf-regext-rdap- > openid-24 > > 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. > > HI Scott, > > please see my comments (I trimmed those where we're in agreement). > > > > 2. In Section 3.1.1. "farv1_session/login" and "farv1_session/logout" > > > are used without any explanation and reference (they are defined later > in > > > the document). > > > > [SAH] Note the complete sentence: "For session-oriented clients (see > > Section > > 3.1.2 and Section 5), the RDAP session is a typical HTTP session > > starting with a farv1_session/login request and ending with either a > > farv1_session/logout request or a timeout." The definitions are > > provided in section 5, hence the forward reference. > > I see it. But I still think the text can be improved a bit. Perhaps: > > "For session-oriented clients (see Section 3.1.2), the RDAP session is a typical > HTTP session starting with a farv1_session/login request and ending with > either a farv1_session/logout request (see Section 5 for definition of both) or > a timeout." [SAH] OK. > > > 3. Sequence diagrams on Figures 1 and 2 are very helpful, but I > > > believe that they > > > can be even more helpful if the order of parties participating in the > > > protocol is the same on both figures (currently "RDAP Client" and "RDAP > > > Server" are swapped on Figure 1 and 2). > > > > [SAH] That was done deliberately because the interactions are slightly > > different. I'll see if I can change one of the diagrams or the other > > to make them consistent without making them more difficult to read. > > My point is that if the order of the parties is the same, the difference in their > interactions will be more evident and thus more understandable (at least to > me). [SAH] I get it. As I said, I'll see if I can modify one of the diagrams. > > > 4. Section 3.1.4.1: "An RDAP server/RP MUST support at least one of > > > these methods of OP > > > discovery." I think that this requirement is too obvious to mention (it's > > > clear that the OP must be known somehow for the whole mechanism > > > to work, and > > > the provided methods include manual configuration, as the last resort). > > > > [SAH] The MUST is needed given that the methods are described using > > OPTIONAL or SHOULD. The MUST makes it clear that at least one is needed. > > My point is that it's obvious, that the OP address must be discovered > somehow, otherwise nothing works. Thus I think that this requirement is > superfluous (for example, you don't state "packets MUST be able to traverse > the network" > or "RDAP server MUST be provided with local policy"). Another part of my > point is that RFC 2119 language is generally used to promote interoperability, > while in this case it just defines prerequisite for the protocol to work... > > Anyway, this is a nit, so it's up to you. [SAH] I'd prefer to keep it. > > > 7. I don't know how important it is, but there is no formal requirements > > > for the language of the Description. Is it ok if the description > > > is provided in, say, Russian :-) ? > > > > [SAH] Interestingly, I can't find anything in RFC 8126 that addresses > > the language used in IANA registry entries. Section 2.2 does say > > "Strings are expected to be ASCII", but there's nothing about > > language. I'll add "English language" to be clear: "a one- or two-sentence, > English language description". > > That was my point :-) [SAH] It's a valid one, too! Scott -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
