Subject: [Dime] RE: comments on draft-ietf-dime-rfc3588bis-09.txt (part 1)

From: <[email-masked]>
Date: Thu, 22 Nov 2007 10:35:38 -0600

Glenn,

________________________________

	From: ext [email-masked] [mailto:[email-masked]] 
	Sent: 22 November, 2007 00:29
	To: [email-masked]; [email-masked]; Loughney
John (Nokia-NRC/PaloAlto)
	Cc: [email-masked]; [email-masked]; [email-masked]
	Subject: comments on draft-ietf-dime-rfc3588bis-09.txt (part 1)

	Author List
	I'm still having a very hard time understanding what Jari & John
are doing on this list: if the rest of the authors of RFC 3588 have been
removed due to lack of involvement in the bis effort, then it seems to
me that they should be, too (unless I've missed a lot of email from
them).  Otherwise, the rest of the original authors should be listed,
too.
	 
	No major comments on this. I did provide text and issues early
on, but I know that I have not had much comment as of late.

	Section 1
	Paragraph 1
	" ...routers and network access servers (NAS) have increased in
complexity
	   and density, putting new demands on AAA protocols." 
	I don't understand what "density means in this context.  Do you
mean "port density"?  Further, is it really the increased complexity and
port density oif the hardware that is placing new demands on the NASs or
is it the increased complexity in the treatment of the users & traffic?
I think the latter... 
	 
	My guess is that it refers to the increased usage of  NASes in
generally, which increases the demands on AAA systems.  Would the term
"usage" be acceptable to replace density. 
	 
	Paragraph 3 & following
	In general, I think that it is much better to use proper names
rather than pointers when referring to external entities; in particular,
"RADIUS [RFC2865] does not" not "[RFC2865] does not".
	 
	Paragraph 5
	"In order to provide universal support for transmission-level
security, and enable both intra- and inter-domain AAA deployments,
Diameter also provides support for TLS.  Security is discussed in
Section 13."
	Why "also provides support"?  Section 13 only mentions TLS...
	 
	Paragraph 9
	Not sure what the purpose of this paragraph is; while it's true
that RADIUS doesn't support data-object security mechanisms, neither
does Diameter (& RADIUS is coming closer to supporting such every
day)...
	 
	Roaming support
	In actual point of fact, it's very difficult to see how Diameter
offers better support for roaming than RADIUS; in particular, TLS
doesn't helpo roamomg at all, at least in the absence of the elusive
global PKI.
	 
	Last paragraph
	It has been considerably more than a decade since AAA protocols
were introduced...

	  I agree with your points here, I suggestion the get fixed in
an update.
	John 

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: Victor Fajardo <[email-masked]>
Date: Fri, 23 Nov 2007 14:20:46 -0500

Hi Glenn,

Thanks for the review.

>     _*Author List*_
>     are doing on this list: if the rest of the authors of RFC 3588
>     have been removed due to lack of involvement in the bis effort,
>     then it seems to me that they should be, too (unless I've missed a
>     /lot/ of email from them).  Otherwise, the rest of the original
>     authors should be listed, too.
>      
>     No major comments on this. I did provide text and issues early on,
>     but I know that I have not had much comment as of late.
>

Speaking on Jari's behalf, his involvement is over a few conferences 
calls specifically on 3588 issues and cleanup so it may not be as 
public. Anyway, given the recent efforts that the previous authors have 
put in, we do plan to update authors list to make it fair.

>     _*Section 1*_
>     _Paragraph 1_
>     mean "port density"?  Further, is it really the increased
>     complexity and port density oif the hardware that is placing new
>     demands on the NASs or is it the increased complexity in the
>     treatment of the users & traffic?  I think the latter... 
>      
>     generally, which increases the demands on AAA systems.  Would the
>     term "usage" be acceptable to replace density. 
>      
>     _Paragraph 3 & following_
>     rather than pointers when referring to external entities; in
>     particular, "RADIUS [RFC2865] does not" not "[RFC2865] does not".
>

Ok.

>     _Paragraph 5_
>     Why "also provides support"?  Section 13 /only/ mentions TLS...
>

Ok. BTW, TLS support is a MUST to implement but its a "SHOULD" to 
deploy. Is that ok with you ?

>     _Paragraph 9_
>     that RADIUS doesn't support data-object security mechanisms,
>     neither does Diameter (& RADIUS is coming closer to supporting
>     such every day)...
>      
>     _Roaming support
>     _In actual point of fact, it's very difficult to see how Diameter
>     doesn't helpo roamomg at all, at least in the absence of the
>     elusive global PKI.
>

Agree. I think we can safely remove these paragraphs.

>     _Last paragraph_

Sure :)

regards,
victor

>
>       I agree with your points here, I suggestion the get fixed in an
>     update.
>     John 
>

---

From: Jari Arkko <[email-masked]>
Date: Fri, 23 Nov 2007 21:47:01 +0200

Glen,
> public. Anyway, given the recent efforts that the previous authors
> have put in, we do plan to update authors list to make it fair.

For what it is worth, my involvement really has been minimal this time.
I did  participate a few conf calls and other private exchanges. I was
planning to  do a full walkthrough of the spec, but have so far not
found time for that. I feel bad about that.

By the way, Hannes brought  up the author list issue early on when
they were starting the bis effort. At that time I said that I wouldn't
mind if my name was dropped off the author list, and that I was not
the main author of RFC 3588 -- I still feel like that. Some other people
from the old list may be worth retaining, however. I also suggested
that they not spend too much time worrying about the list beforehand,
because its hard to predict who does most of the work over
the course of a long project. If the project is now close to its
end, it may be a good time to figure out who the right names
on the list are. Please remember that you have many tools to
deal with people with varying degrees of involvement, including
the author list, contributor and acknowledgment sections, etc.

Jari