Subject: [weirds] About to push the approve button, but...

From: Pete Resnick <[email-masked]>
Date: Mon, 29 Dec 2014 16:01:58 -0600

Doing my final review of the docs, it looks like using-http, rdap-sec, 
and object-inventory are ready to go, and I want to do one final check 
on bootstrap in light of Peter's comments, but that looks good too. 
However, as I was about to approve the lot, I noticed a few issues in 
rdap-query and json-response that seem to have been dropped during IESG 
Eval. On some of them, perhaps the intention was to say, "Thanks, but 
we're leaving that as-is", but all I see is silence.

On rdap-query, from Ted's comments:

On 10/29/14 5:45 PM, Andy Newton wrote:
> On Oct 29, 2014, at 2:47 PM, Ted Lemon<[email-masked]>  wrote:
>    
>> Point A:
>>
>> In 3.1.2:
>> ...
>>      
> The point is: don’t do ASDOT… which is an issue for 4-byte as numbers. We should probably actually say that, and split apart the first paragraph to put the examples closer to it.
>
>> Point B:
>>
>> Section 6 appears to be confusing presentation and representation.   A
>> client might well present a UI that shows U-labels, but use A-labels on
>> the back end.   The text as written here really doesn't make sense.
>> What are you trying to say?   I think that you shouldn't confuse what's
>> presented to the user with what's sent on the wire.   Possibly this is
>> related to the confusion over A-labels and U-labels that I called out in
>> Point 2 of the discuss.
>
> [No response]
>    

And later:

On 10/29/14 6:49 PM, Ted Lemon wrote:
> My concern is that it will be used for data mining by people other than owners of nameservers.   I don't think there's much that can be done to mitigate this, though, so I'll take it out of the DISCUSS.   It wouldn't hurt to mention it specifically in the security considerations section, but I'll leave that up to you.
>    

Sounds like Point A was supposed to get some additional text, but 
nothing changed, and that Point B and the requested addition to Security 
Consideration were ignored.

On json-response, Stephen's last two points:

On 10/30/14 8:47 AM, Stephen Farrell wrote:
> - p21, the list following the example contains items that were
> not in the example - this is unclear writing. Are you saying
> that the list is normative or not? If so, you need to say so.
> If not, why go beyond the example? The same point applies to
> the lots of other examples that follow.
>
> - 10.2.X: there's a lot of stuff here that wasn't described. I
> wouldn't be surprised if that causes interop problems.
>    

and both of Ted's points:

On 10/29/14 2:40 PM, Ted Lemon wrote:
> Point 1:
>
> In 4.3:
>     It is the job of the clients to determine line breaks, spacing and
>     display issues for sentences within the character strings of the
>     "description" array.  Each string in the "description" array contains
>     a single complete division of human readable text indicating to
>     clients where there are semantic breaks.
>
> What do you mean by "semantic breaks"?   Paragraph breaks?   Sentence
> breaks?   Dependent clause breaks?   This doesn't make sense.   I'm not
> going to raise a discuss on it because I don't think it affects
> interoperability, but I have no idea how to implement a client to display
> this in a way that will make sense to the user.
>
> Point 2:
>
> A general question that occurred to me in reading 5.5, which also applies
> to 5.4: should you have some text talking about how the link member of a
> network or autnum object is generated?  Both networks and autnum objects,
> as I understand it, can be gotten by querying any number in the range
> they enclose.   But of course the link member isn't going to enumerate
> all the possible queries that could return the particular object
> containing that link member.   So how is the value that's returned
> chosen?  Is it the lowest number in the range?   The number that was used
> in the query that returned the object?   Some other number?
>
> I don't think you need to change anything, but it might be worth
> discussing this in sections 5.4 and 5.5.
>    

These all look completely dropped.

Can the authors give me a status on the above comments?

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 31 Dec 2014 00:30:13 +0000

> -----Original Message-----
> From: weirds [mailto:[email-masked]] On Behalf Of Pete Resnick
> Sent: Monday, December 29, 2014 5:02 PM
> To: [email-masked]
> Cc: [email-masked]; draft-ietf-weirds-rdap-
> [email-masked]; [email-masked]
> Subject: [weirds] About to push the approve button, but...
> 
> > The point is: don't do ASDOT... which is an issue for 4-byte as
> numbers. We should probably actually say that, and split apart the
> first paragraph to put the examples closer to it.

I'll leave this one to Andy.

> >> related to the confusion over A-labels and U-labels that I called

There was no response because this was part of our "we don't know what to say about Ted's IDN issues" off-list discussion. If I were to respond now I would say "what we have there came from our best IDN experts and I'm inclined to leave it alone unless they say otherwise".

> > My concern is that it will be used for data mining by people other
> than owners of nameservers.   I don't think there's much that can be
> done to mitigate this, though, so I'll take it out of the DISCUSS.   It
> wouldn't hurt to mention it specifically in the security considerations
> section, but I'll leave that up to you.
> >
> 

I have to disagree with the suggestion to add text about data mining. This isn't WHOIS, and we wrote a security document that describes client identification, authorization, and access control features in RDAP to address that issue with WHOIS. There was no direct response simply because the point got lost in the flurry of higher priority discuss topics.

> Can the authors give me a status on the above comments?

Status for rdap-query provided above. I'll need to talk to Andy about json-response.

Scott

---

From: Pete Resnick <[email-masked]>
Date: Wed, 31 Dec 2014 10:48:50 -0600

> I'll leave this one to Andy.

Ack. He promised to get back to me when he was not hopped-up on cough 
medicine.

>>>> Point B:
>>>>
>>>> Section 6 appears to be confusing presentation and representation. 
>>>> A client might well present a UI that shows U-labels, but use 
>>>> A-labels on the back end. The text as written here really doesn't 
>>>> make sense. What are you trying to say? I think that you shouldn't 
>>>> confuse what's presented to the user with what's sent on the wire. 
>>>> Possibly this is related to the confusion over A-labels and 
>>>> U-labels that I called out in Point 2 of the discuss.
>>> [No response]
>>>        

Good. That's my gut too. He doesn't like this sentence:

    Clients capable of
    processing non-ASCII characters may prefer a U-label since this is
    more visually recognizable and familiar than A-label strings, but
    clients using programmatic interfaces might find it easier to submit
    and display A-labels if they are unable to input U-labels with their
    keyboard configuration.

And he's right, that sentence is mixing apples and oranges: You can 
display a U-label or an A-label as a decoded string, and which encoding 
you use internally doesn't effect that. But I know what was meant, and I 
don't think it is likely to confuse implementers, so I don't see a big 
need to change it.

>> nothing changed, and that Point B and the requested addition to
>> Security Consideration were ignored.
>>      
> I have to disagree with the suggestion to add text about data mining. This isn't WHOIS, and we wrote a security document that describes client identification, authorization, and access control features in RDAP to address that issue with WHOIS.

Seems like a fair response to me.

> There was no direct response simply because the point got lost in the flurry of higher priority discuss topics.
>    

Yep. Just making sure we have a record on the list that we saw the issue 
and there was a disposition.

>>> breaks?   Dependent clause breaks?   This doesn't make sense.   I'm
>>> not going to raise a discuss on it because I don't think it affects
>>> interoperability, but I have no idea how to implement a client to
>>> display this in a way that will make sense to the user.
>>>
>>> Point 2:
>>>
>>> A general question that occurred to me in reading 5.5, which also
>>> applies to 5.4: should you have some text talking about how the
>>> link member of a network or autnum object is generated?  Both
>>> networks and autnum objects, as I understand it, can be gotten by
>>> querying any number in the range they enclose.   But of course the
>>> link member isn't going to enumerate all the possible queries that
>>> could return the particular object containing that link member.
>>> So how is the value that's returned chosen?  Is it the lowest
>>> number in the range?   The number that was used in the query that
>>> returned the object?   Some other number?
>>>

Thanks.

pr

---

From: Andy Newton <[email-masked]>
Date: Wed, 31 Dec 2014 19:46:41 +0000

>> the lots of other examples that follow.

Well, this is a general problem with describing JSON without a schema language: clarity relies on the copious use of examples. This section lays out an example of entity as it might be rendered by an RIR, then lays out the normative structure, then gives an elided example, then gives an example as it might be rendered by a DNR. I fail to see how rearranging things helps or giving an example with ALL valid fields would be clearer. And the words "This object has the following members” precedes the list. How can that be made clearer?

>> wouldn't be surprised if that causes interop problems.

Every value in that section as a description field. And to my knowledge, none of it has shown up as an issue in our interop sessions.

>> this in a way that will make sense to the user.

This was discussed on the list and, as I recall, there was an issue over these being considered paragraph breaks. The current words raised no objections. We can change it, but it is just gonna make somebody else unhappy for little benefit.

>> discussing this in sections 5.4 and 5.5.

I don’t think text discussing how to generate links will be helpful because the solution is just to pick a number (perhaps the lowest or highest) in the range and go for it. Or use object handles (synthetic keys). It’s an implementation issue that could have many solutions.

-andy

---

From: Andy Newton <[email-masked]>
Date: Wed, 31 Dec 2014 19:54:52 +0000

On Oct 29, 2014, at 2:47 PM, Ted Lemon<[email-masked]<mailto:[email-masked]>>   wrote:

Point A:

In 3.1.2:
...

Ack. He promised to get back to me when he was not hopped-up on cough medicine.

The current draft says “AS Plain” and references 5396. I think that is clear enough. We shouldn’t have to specify everything a client shouldn’t do because that is a big universe.

-andy

---

From: Pete Resnick <[email-masked]>
Date: Wed, 31 Dec 2014 14:19:38 -0600

On 12/31/14 1:54 PM, Andy Newton wrote:

> The current draft says "AS Plain" and references 5396. I think that is 
> clear enough. We shouldn't have to specify everything a client 
> shouldn't do because that is a big universe.

Sounds OK.

pr

---

From: Pete Resnick <[email-masked]>
Date: Wed, 31 Dec 2014 14:21:18 -0600

> Well, this is a general problem with describing JSON without a schema language: clarity relies on the copious use of examples. This section lays out an example of entity as it might be rendered by…

I think it's the "This" that's the problem: It's not that the object in 
the above example has the following members; it's that an object of the 
particular type *can* contain the following members. Saying that is 
probably a good idea. So for 5.1:

The entity object class can contain the following members:

For 5.2, simply s/has/can contain, and so on for the other sections. 
That would certainly clarify.

> Every value in that section as a description field. And to my knowledge, none of it has shown up as an issue in our interop sessions.

Seems like a satisfactory response to me.

> This was discussed on the list and, as I recall, there was an issue over these being considered paragraph breaks. The current words raised no objections. We can change it, but it is just gonna make…

I'm OK with leaving it. It's basically saying that the creator of the 
array decided on where to put breaks, and the interpreter of the array 
can do what it will with that information.

> I don’t think text discussing how to generate links will be helpful because the solution is just to pick a number (perhaps the lowest or highest) in the range and go for it. Or use object handles (…

Ack.

So, I wouldn't mind a quick edit of those lines in json-response, and 
I'll consider the rdap-query issues addressed.

Thanks.

pr