Subject: [Dime] I-D Action:draft-ietf-dime-extended-naptr-04.txt

From: [email-masked]
Date: Thu, 06 Jan 2011 11:15:02 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF.

	Title           : Diameter Extended NAPTR
	Author(s)       : M. Jones, et al.
	Filename        : draft-ietf-dime-extended-naptr-04.txt
	Pages           : 12
	Date            : 2011-01-06

The Diameter base protocol specifies mechanisms whereby a given realm
may advertise Diameter nodes and the supported transport protocol.
However, these mechanism do not reveal the Diameter applications that
each node supports.  A peer outside the realm would have to perform a
Diameter capability exchange with every node until it discovers one
that supports the required application.  This document describes an
improvement using an extended format for the Straightfoward-NAPTR
(S-NAPTR) Application Service Tag that allows for discovery of the
supported applications without doing Diameter capability exchange
beforehand.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dime-extended-naptr-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Mark Jones <[email-masked]>
Date: Fri, 7 Jan 2011 15:49:23 -0500

This revision addresses the comments received from Itsuma Tanaka (issue
#13), Avi Lior (issue #14) and Lionel Morand (issue #15) during WGLC. As the
comments received were mainly editorial, I understood from the chairs at
IETF#79 that they now would request a "mini-WGLC" asking if someone has
concerns due to the changes.

DIME chairs, Please can you do the necessary to kick off a "mini-WGLC" on
this draft.

Thanks
Mark

On Thu, Jan 6, 2011 at 2:15 PM, <[email-masked]> wrote:

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

---

From: Jouni <[email-masked]>
Date: Sat, 8 Jan 2011 00:51:03 +0200

Folks,

We will rerun a short WGLC for draft-ietf-dime-extended-naptr-04 since there were some bigger restructuring on the document. The WGLC starts as of today 8th Jan 2011 and ends 14th Jan 2011 23:59 CET+1. If you have substantial technical comments, please post them to the list. Purely editorial comments can be mailed directly to the authors. Silence will be taken as acceptance.

- Jouni (as a Dime co-chair)

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 8 Jan 2011 15:46:10 +0700

Would somebody tell me again why we're issuing an update for a document that
will be obsolete very soon?

This draft appears to be in some conflict w/rfc3588bis; in particular, both
request that IANA register the same set of S-NAPTR Application Protocol
Tags. 

This draft updates RFC 3588 but says nothing about 3588bis; 3588bis says
nothing about this document.  This seems to lead to a dead-end.

This draft is considerably more detailed WRT S-NAPTR than 3588bis.  Why? 

Hope this helps.

 ~gwz

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jouni
> Sent: Saturday, January 08, 2011 5:51 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Dime] WGLC for draft-ietf-dime-extended-naptr
> 
> Folks,
> 
> We will rerun a short WGLC for draft-ietf-dime-extended-naptr-04 since
> there were some bigger restructuring on the document. The WGLC starts as
> of today 8th Jan 2011 and ends 14th Jan 2011 23:59 CET+1. If you have
> substantial technical comments, please post them to the list. Purely
> editorial comments can be mailed directly to the authors. Silence will
> be taken as acceptance.
>

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 8 Jan 2011 15:58:45 +0700

Shouldn't the title actually be something like "Diameter S-NAPTR Usage"?

Change the first page header to read 

Network Working Group                                           M. Jones
Internet-Draft                                                  Bridgewater
Systems

instead of 

Diameter Maintenance and                                        M. Jones
Extensions (DIME)                                               Bridgewater
Systems

The abbreviated title ("dime-extended-naptr") is just silly (and not
anything like an abbreviation).

There is no Application Service Tag define for the Diameter Base Protocol in
this draft (although there is in rfc388bis).  Since The Diameter Base
protocol includes rudimentary accounting functionality it doesn't seem
completely unreasonable that Diameter Base might be used as a stand-alone
app.

Hope this helps.

 ~gwz

---

From: Mark Jones <[email-masked]>
Date: Mon, 10 Jan 2011 15:13:00 -0500

Hi Glen,

Thanks for the review.

> will be obsolete very soon?

I direct your attention to the "can of worms" presentation from IETF#76. :)

http://www.ietf.org/proceedings/77/slides/dime-5.pdf

At the time we started this draft, it was uncertain whether 3588bis
would beat it to publication. So we decided to proceed optimistically
assuming the SNAPTR draft would get published first with the
understanding that we'd have some updates to do if we were wrong.

The application-neutral aspects of SNAPTR (e.g "aaa:diameter.sctp")
were also contributed to 3588bis to ensure that 3588bis would be
functionally complete if it got published first and this draft would
come along later to add the application-specific SNAPTR entries (e.g.
"aaa+ap5:diameter.sctp").

> nothing about this document.  This seems to lead to a dead-end.

If 3588bis is published first, we will need to change this draft to
state that it updates 3588bis instead of 3588 and remove the duplicate
SNAPTR protocol tag entries.

> This draft is considerably more detailed WRT S-NAPTR than 3588bis.  Why?

This draft includes the level of detail required to satisfy the
reviewers. The extra detail may be explained by the
application-specific S-NAPTR grammar/usage being slightly more
complicated than the application-neutral one in 3588bis. Do you think
some essential details are missing from the 3588bis procedures?

Regards
Mark

---

From: Mark Jones <[email-masked]>
Date: Mon, 10 Jan 2011 15:46:43 -0500

Hi Glen,

(Typo in my previous email: s/IETF#76/IETF#77/. The URL was correct though.)

> Shouldn't the title actually be something like "Diameter S-NAPTR Usage"?

I like that. Unless I hear objections, I'll pick it up in the next revision.

> Extensions (DIME)                                               Bridgewater

Agreed.

> anything like an abbreviation).

It originally got that title because we were extending NAPTR until we
realized it was obsoleted by DDDS and SNAPTR should be used instead.
I'd prefer to keep the 'silly' title now since it will disappear when
it gets an RFC number and a rename at this stage might make it more
difficult to track the draft evolution.

> this draft (although there is in rfc388bis).

AFAIK, rfc3588bis only reserves a tag for "aaa" which means ANY
Diameter application.

> Since The Diameter Base

Ok, I hadn't appreciated that stand-alone usage of Base. Looking at
section 7.1, it appears to be missing two entries: one for "aaa" and
one for "aaa+ap0". The "aaa" entry could be deleted if rfc3588bis is
published first.

Thanks
Mark

---

From: Sebastien Decugis <[email-masked]>
Date: Tue, 11 Jan 2011 10:44:17 +0900

Hi,

> one for "aaa+ap0". The "aaa" entry could be deleted if rfc3588bis is
If I understand correctly the discussion, I think you mean here
"aaa+ap3". Application 0 is used for the "one hop only" messages
(CER/CEA, DWR/DWA...) and is supported by ALL peers (so there is no
point in having it defined here). Application 3 is the "rudimentary
accounting functionality" defined in rfc3588(bis).

I apologize if my remark is irrelevant...

Best regards,
Sebastien.

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)

---

From: Mark Jones <[email-masked]>
Date: Fri, 21 Jan 2011 10:27:15 -0500

Hi Sebastian,

> accounting functionality" defined in rfc3588(bis).

Good catch. I mistakenly thought base accounting used app id 0. As you
point out, an app id of 0 is only used for CER/CEA, DWR/DWA, DPR/DPA
so it does not appear useful as a stand-alone app. Unless someone has
an example where "aaa+ap0" would be useful, I won't add it to the next
rev.

> I apologize if my remark is irrelevant...

Highly relevant. Thank you.

Regards
Mark