Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt

Marc,

    It seems that you are focusing too much in that "an XML is very easy
to parse" but you are forgeting the scalability issues that lazy
programers may be.

    As John said in other email we could use all the MUST, MUST NOT that
we can imagine and even though there is no guarantee that those
guidelines would be follow.

    I am not saying that we should not use XML in IANA, just saying that
we must not minimize the operational impact that it could be to IANA.

Regards,
as
   
On 6/21/13 5:40 AM, Marc Blanchet wrote:
> Le 2013-06-20 à 18:03, "John R Levine" <johnl@taugh.com> a écrit :
>
>>> an XML file is just a small file on the Internet. Cached, there is a copy everywhere.
>> I have a physical server in a nearby hosting center and some VPSes in Pennsylvania.  I'm fairly sure there are no http caches in front of any of them and even more sure there are no https caches.  IANA's web servers appear to be on a single physical network in California, not mirrored using Akamai or the like.
> ok. I think we are getting way too deep here and becomes completly irrelevant. 
>
>> The RDAP clients I expect to use won't be full web browsers,
> don't need to.
>
>> and they're not on consumer ISPs with awful "transparent" web caches. I also have no interest in dragging a big XML parser into a tiny JSON application.
> then, I'm against that argument. This is pretty straightforward parsing.
>
>> You know, if we assume that the TTL on the IANA file is a year or two, my baked-in+upgrade approach is functionally equivalent to yours and depends less on third parties who may not want to be volunteered.
> there is implementation specificities (that are outside of the scope of the IETF) and there are interop stuff.
>
> What I'm saying is that the client should get the data from the IANA registry. Does it do it often, not often, upgrade, etc... is not in IETF document. However, we should provide some guidance about what to do. The implementor may decide to use or not use the guidance. Therefore, baked-in+upgrade or whatever is irrelevant to me, as long as they use the same source, which is what I care.
>
> marc.
>
>
>
>> R's,
>> John
>>
>>>> So in 2119-ese,
>>>>
>>>> RDAP clients SHOULD use a hints table to select an initial numbers server, with some way to update the table, which might be as crude as installing a new version of the RDAP client,
>>>>
>>>> clients MAY use pool.numbers.rdap.arpa as an initial server if there is no hints table available, or the target isn't in the table (they will whether or not we say they can, so we might as well provide a well known name for it), and
>>>>
>>>> clients MUST use <tld>.domain.rdap.arpa as an initial server for TLD.
>>>>
>>>> In each case, the protocol is https.  Anyone who plans to run an RDAP server and won't be able to provide https should speak up now.
>> Regards,
>> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
>> "I dropped the toothpaste", said Tom, crestfallenly.
> _______________________________________________
> weirds mailing list
> weirds@ietf.org
> https://www.ietf.org/mailman/listinfo/weirds