FWD: Re: draft-carroll-dynmobileip-cdma-04.txt

[Thomas Narten <narten@us.ibm.com>]

Here is an older note on this document.  I'd like advice from the
aaa-doctors on what the right thing to do is, per the question I asked
below.

And responding specifically to a comment from David that was forwarded
to the IESG:

> I will digress, for a moment, to say that I disagree with the current
> policies on individual submissions that have the effect of violating
> normative requirements of Standards Track protocols.

I responded to this as follows:

Thomas Narten <narten@rotala.raleigh.ibm.com> writes:

> It is _not_ my understanding (per 3932) that the IESG is obligated to
> approve documents that conflict with IETF efforts.

> RFC 3932 specifically says:

>    The IESG may return five different responses, any of which may be
>    accompanied by an IESG note to be put on the document if the RFC
>    Editor wishes to publish.

> ...
>       
>    4. The IESG thinks that this document violates IETF procedures for
>       <X> and should therefore not be published without IETF review and
>       IESG approval.

> I would argue that:

> > individual submissions that have the effect of violating
> > normative requirements of Standards Track protocols.

> fall under item 5.

In any case, this document is a tricky one, but one that we should get
closure on and then move on (either way).

Thomas
------- Forwarded Message

From: Bernard Aboba <aboba@internaut.com>
To: narten@rotala.raleigh.ibm.com
Cc: "Nelson,David" <dnelson@enterasys.com>,
   Steven Bellovin <smb@research.att.com>, Russ Housley <housley@vigilsec.com>,
   David Kessens <david.kessens@nokia.com>, Bert Wijnen <bwijnen@lucent.com>
Date: Sun, 10 Oct 2004 14:06:47 -0700 (PDT)
Subject: Re: draft-carroll-dynmobileip-cdma-04.txt

Thanks for your note.  Since I last looked at this specification a while
back, I am going to have to take a few days to review it again to refresh
my memory before responding.

On Fri, 8 Oct 2004, Thomas Narten wrote:

> Bernard, David,
>
> In your role as radext chairs and also as aaa-doctors, I'd like some
> advice here.
>
> The above document was submitted to the RFC editor quite some time
> ago. It received a number of IETF reviews, and Bernard in particular
> flagged how the document violated a MUST NOT in the radius spec. See
> the comments in ID tracker for some of the details.
>
> It has since stalled, mostly because I think the authors just want to
> publish the document as is (it documents something that they have done
> and they are not willing to make technical changes), but we never
> really got past the review concerns.
>
> However, if the document were submitted today, the IESG would review
> it along the lines outlined in draft-iesg-rfced-documents-03.txt,
> which means we'd be much more inclined to publish it with some sort of
> disclaimer than block it as somehow "harmful".
>
> This one is still tricky, in that it (IMO) does "embrace-and-extend"
> radius in ways that I think the IETF has a right to say "not
> acceptable", if it felt strongly. But if we were to attempt to do so,
> we'd need to have pretty good arguments (e.g., with a WG or other
> experts willing to say this), as we may end up with a nasty fight with
> the RFC Editor, who (in email about this draft that I've seen) has not
> yet been convinced that the radius issues are a "big deal". Not saying
> we shouldn't have that fight, just observing that it may well be a big
> one with repurcussions, so we should understand where we might be
> heading.
>
> So, what should we do with this one? My personal inclination is to
> publish it with one of the standard disclaimers along with some sort
> of note making it clear that this spec violates the radius spec,
> perhaps with some words about why we are publishing it anyway or some
> such.
>
> Thoughts on this, or what an appropriate note (on the radius issue)
> would be if were willing to let it go?
>
> Thomas
>

------- End of Forwarded Message