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

[Pete Resnick <[e-mail]>]

On 12/30/14 6:30 PM, Hollenbeck, Scott wrote:
>> 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<[e-mail]>   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.
> 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]
>>>        
> 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".
>    

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.

>> 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.
>>      
> 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.

>> 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?
>>      
> Status for rdap-query provided above. I'll need to talk to Andy about json-response.
>    

Thanks.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - [phone]