Hello Erik,

thanks for your detailed review and feedback. Concerning the last point
(as Med already responded to the other two): We had picked 2490 over
1883, because it is a draft-standard, and not a proposed standard;
Also, looking at general IPv6 reception, 1998 is usually more seen as
'the year' IPv6 came out.

However, that does not really make for strong feelings either way, and
you point (picking the earliest) makes at least as much sense to me as
the reasoning we used.

So we would be happy to change that in the next revision.

With best regards,
Tobias


> ---------------------------------------------------------------------
> -
> COMMENT:
> ---------------------------------------------------------------------
> -
> 
> # Internet AD comments for draft-ietf-dnsop-3901bis-10
> CC @ekline
> 
> * comment syntax:
>   - https://github.com/mnot/ietf-comments/blob/main/format.md
> 
> * "Handling Ballot Positions":
>   -
> https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> 
> ## Comments
> 
> ### S4.1
> 
> * "IPv4-converted IPv6 addresses"
> 
>   As Geoff Huston pointed out, this is not a formal term.  I
> recommend
>   adopting his suggested alternative:
> 
>   "Authoritative DNS servers SHOULD NOT use IPv4-Compatible IPv6
> Addresses
>   and IPv4-Mapped IPv6 Address [RFC4291]".
> 
> ### S4.2
> 
> * Geoff highlights some concerns with recurser forwarding and the
> lack of
>   a protocol-based mechanism for loop avoidance or loop termination.
> 
>   One possibility here might be to say that recursers SHOULD NOT
> forward
>   to other recursers in the manner described unless the operator can
> be
>   sure that no loops can ever formed (the means by which this is to
> be
>   done would, of course, be outside the scope of this document).
> Operators
>   choosing to employ this kind of recurser forwarding may open their
>   infrastructure to denial of resource attacks.
> 
> ## Nits
> 
> ### S1
> 
> * If you're going to reach for an early IPv6 RFC then 2460 itself was
>   replacing 1883 (1998 vs 1995).
> 
> 

-- 
My working day may not be your working day. Please do not feel obliged 
to reply to my email outside of your normal working hours.
-----------------------------------------------------------------
Tobias Fiebig, Forschungsgruppe Internet Architecture (INET) 
Max-Planck-Institut für Informatik, Campus E14, 66123 Saarbrücken
E1 4 - Raum 517 mobil: +31 616 80 98 99

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to