search

moonshiner / draft-ietf-deleg-requirements-old

Other
2 stars 0 forks source link

Cfa Comments from Paul Wouters #14

Open moonshiner opened 2 weeks ago

moonshiner commented 2 weeks ago 
     DELEG must be able to secure delegations with DNSSEC. Ideally it should
     be able to convey an even stronger security model for delegations than
     currently exists.

I don't understand this? What is an "even stronger security model" than DNSSEC ?

     DELEG must support updates to delegation information with the same
     relative ease as currently exists with NS records. Changes should
     take the same amount of time (eg, controlled by a DNS TTL) and
     allow a smooth transition between different operational platforms.

This seems to talk about DNS outside of the EPP/registration world? I thought the goal was to be "easier" then going through EPP/webportals ? I thought current "NS updating" is NOT "relative easy" (for a DNS provider that is not also the Registrar) ?

     DELEG must be incrementally deployable and not require any sort
     of flag day of universal change to be effective.

can "to be effective" be removed? That makes the whole clause rather strange.

     DELEG should enable a DNS operator to manage DNS service more
     completely on behalf of domain administrators. For example, DELEG
     could address long-standing issues of DNSSEC record maintenance
     that now often depend on registrant / registrar interaction.

Should this not be a "hard requirement"?

vttale commented 2 weeks ago

For the first one, the issue is that right now the records in a delegation are not signed. Most of the discussion around a new method has included the notion that they would be signed, which is stronger. I don't know that it needs more words in the document to clarify since it hasn't been brought up by others as confusing, but maybe just adding "where delegations are unsigned" after "currently exists" would be sufficient.

For "This seems to talk about DNS outside of the EPP/registration world" I'm not quite sure what the issue is here. The requirement is simply that updating DELEG shouldn't be intrinsically harder than updating NS would be, via whatever mechanism is being used to do it.

I disagree that "to be effective" makes that sentence all that strange, but also don't think it's adding much and don't really care whether it stays or goes.

For the last thing, no I don't think it should be a hard requirement. The doc is fairly clearly that the hard requirements are mostly about what we're avoiding breaking, and the soft requirements are about the problem space that is trying to be solved.