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." > > 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). > > 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. > > 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 :-) Regards, Valery. > Scott -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
