Re: Last Call: <draft-ietf-ianaplan-icg-response-06.txt> (Draft Response

John, thank you for the feedback!

> > At the top of page 8, it refers to disputes about policy.  To me the
> > question is ambiguous: does it mean disputes within the IETF, or
> > disputes between the IETF and IANA, e.g., "we can't implement that"?
> > As far as I know, there's never been a significant policy dispute with
> > IANA, so you might as well say so for anyone who was wondering about
> > that question.
Thanks for pointing this out. The text refers to policy within IETF and 
disputes within IETF. Perhaps that could be clarified. Eliot?

(Given the roles for the different parties, there should really not be policy 
disputes between IETF and IANA. However, there are concerns of implementation, 
and occasionally there are question marks on whether the specified policy is 
implementable, or implementable at a reasonable effort. Consider a hypothetical 
registry that would increase data and workload multifold; IANA would be right 
to question such changes, particularly if those were not understood at the time 
of discussion the said policy. Nevertheless, such concerns should be fed into 
to the usual IESG approval, IAB oversight, etc. processes, and resolved per 
community consensus. FYI - minor issues with policies are discovered by IANA 
almost daily, and those concerns are fed to the processes and resolved. Most of 
this is just mistakes and unclear instructions in RFCs-to-be.) 

> > Following that, there is a discussion of all the stuff we don't want
> > to change, all of which is fine.  But it doesn't say other than sort
> > of implicitly in #3 on page 13 that the IETF needs a binding agreement
> > with the IANA operator that has protections for the IETF community
> > that are substantially the same as those in the MOU in RFC 2860.  It
> > really needs to say that explicitly.
> This was debated substantially in the working group.  
That is the main thing to observe. The topic has gotten a lot of attention 
during WG discussion, and a particular outcome emerged, and I believe the draft 
reflects that.

Jari

signature.asc
Description: Message signed with OpenPGP using GPGMail