Re: Last Call: <draft-iab-2870bis-01.txt> (DNS Root Name Service Protocol and Deployment Requirements) to Best Current Practice

["Carlos M. Martinez" <[e-mail]>]

Maybe you can better explain to us where you draw the line of
'operational practices' vs 'requirements'

Requiring IPv6, or anycast, or feature X is, in my opinion, a just that,
a requirement.

Operational practice would dictate HOW you fulfill the IPv6, or anycast,
or X requirement.

~Carlos

On 30/05/2014 13:09, manning bill wrote:
> then you won’t mind if the IETF write RFCs to dictate operational policies to RIRs?
> 
> 
> /bill
> Neca eos omnes.  Deus suos agnoscet.
> 
> On 30May2014Friday, at 8:56, Carlos M. Martinez <[e-mail]> wrote:
> 
>> Actually, you got me thinking. Why not require anycast, indeed. I think
>> at some point it will become necessary. Maybe as a SHOULD this time.
>>
>> The argument of 'operational autonomy' cannot be sacrosanct. If you
>> agree to provide a service that the whole internet depends on, then you
>> need to comply with a few requirements. If you can't / won't, well...
>> you can opt out.
>>
>> Operating a root server is not a god-given right or burden. Just opt out
>> if you cannot fulfil the requirements the whole Internet needs. Some
>> things just come with the territory.
>>
>> If, on the other hand, you operate some random email server out there,
>> then yes, I agree you are pretty much the king of your castle. You are
>> free to not do DMARC if you don't want to.
>>
>> I do agree with Patrik that the enforcement part is not the IETF's
>> responsibility. That lies elsewhere. But past failures in enforcement
>> should not deter the IETF of setting the requirements the IETF deems
>> necessary for the correct operation of the Internet.
>>
>> ~Carlos
>>
>>
>> On 29/05/2014 18:24, manning bill wrote:
>>> and why not require anycast?  if your going to meddle in other companies operations, be bold!
>>>
>>>
>>> /bill
>>> Neca eos omnes.  Deus suos agnoscet.
>>>
>>> On 29May2014Thursday, at 14:13, Carlos M. Martinez <[e-mail]> wrote:
>>>
>>>> I need to clarify something here (thanks TM for spotting this).
>>>>
>>>> I didn't mean to say that the IETF should require all root server
>>>> operators to provide anycast copies. I'd very much would like them to,
>>>> but there yes, I don't think the IETF can/should require that.
>>>>
>>>> My comment about 'this requirement is well within...' was only intended
>>>> to apply to the IPv6 issue.
>>>>
>>>> regards,
>>>>
>>>> ~Carlos
>>>>
>>>> On 29/05/2014 17:18, Carlos M. Martinez wrote:
>>>>> I think there is enough consensus saying that root server operators MUST
>>>>> support IPv6. I think it's hard to argue that the Internet needs this to
>>>>> move to IPv6, as otherwise we'll be saying that it'll be ok for future
>>>>> networks to not be able to access some root servers, or putting the
>>>>> burden of supporting all IPv6 on a subset of root servers.
>>>>>
>>>>> If you add that not all root server operators offer anycast copies, or
>>>>> do it in a limited way, well, we could be putting the IPv6 internet in a
>>>>> fragile position.
>>>>>
>>>>> IMO, setting this requirement is well within the core competencies of
>>>>> the IETF.
>>>>>
>>>>> Then comes the question what to do (if anything) with those root server
>>>>> operators who chose to ignore this MUST.
>>>>>
>>>>> IMO, This is probably outside the IETF's sphere, and it should be
>>>>> possible to even say so in the proposed document.
>>>>>
>>>>> cheers!
>>>>>
>>>>> ~Carlos
>>>>>
>>>>> On 29/05/2014 05:24, Jari Arkko wrote:
>>>>>>
>>>>>>> I would like every A-M.root-servers.net have an A and AAAA record.
>>>>>>>
>>>>>>> I don't care how the root-server operators decide to partition to workload
>>>>>>> among hardware.
>>>>>>
>>>>>> Yes, that is my view as well.
>>>>>>
>>>>>>> Over time we will need more v6 responders and fewer v4
>>>>>>> responders.
>>>>>>> I don't think that there is, or should be, any requirement that v4 and v6 be
>>>>>>> answered by the same system, and given anycast, they might even be in
>>>>>>> different locations.
>>>>>>>
>>>>>>> I think that the current text captures this just fine:
>>>>>>
>>>>>> Agreed.
>>>>>>
>>>>>> Jari
>>>>>>
>>>>
>>>
>>
>