Subject: [Dime] pre-revision of RFC3588bis-27

From: jouni korhonen <[email-masked]>
Date: Fri, 19 Aug 2011 18:08:13 +0300

Folks,

Finally got my lazy *ss up and did a revision -27. Actually now that the S-NAPTR registry thing has stabilized it made sense to complete RFC3588bis. The intermediate version can be found here:
http://dimowine.neonsite.net/draft-ietf-dime-rfc3588bis-27.txt

Following things were added/changed since -26:

0) note on Idnits:
 * 2 warnings on non-RFC2606-compliant FQDNs are bogus
 * 2 warnings on missing references are bogus
 * don't know the issue about boilerplate.. anyone?

1) Added text to Abstract that this document obsoleted RFC 3588 -> pleases Idnits

2) Section 1.1.3.
 * s/E2ESequence/E2E-Sequence
 * see http://www.ietf.org/mail-archive/web/dime/current/msg04671.html

3) Section 1.2
 * rewording Diameter Peer definition
 * removed the Transport definition
 * see http://www.ietf.org/mail-archive/web/dime/current/msg04805.html

4) Section 1.2
 * reworded Redirect agent definition a bit
 * see http://www.ietf.org/mail-archive/web/dime/current/msg04810.html

5) Section 1.3.4
 * added a new situation when a new application id is needed i.e. if
   new AVP flag bits get added
 * see http://www.ietf.org/mail-archive/web/dime/current/msg04808.html

6) Section 4.1
 * clarified the handling of AVP flag bits
 * see http://www.ietf.org/mail-archive/web/dime/current/msg04808.html

7) Section 5.3.3
 * clarification on Vendor-Id AVP
 * see http://www.ietf.org/mail-archive/web/dime/current/msg04741.html

8) Sections 7.1.3 and 7.1.5
 * Result-Code numbering is now back to RFC3588 numbers..
 * I did not add any notes on redundancies:
   o DIAMETER_INVALID_BIT_IN_HEADER vs. DIAMETER_INVALID_HDR_BITS
   o DIAMETER_INVALID_AVP_BIT_COMBO vs. DIAMETER_INVALID_AVP_BITS
  
   There is a difference between 3xxx vs. 5xxx errors. And
   I think it is good to have this distinction here.

 * see http://www.ietf.org/mail-archive/web/dime/current/msg04616.html

9) Section 11
 * IANA considerations only contains those things that get changed
   from RFC3588 or are new to RFC3588bis. Also some other things
   changed there.
 * added experimental use range to align with RFC5719
 * see http://www.ietf.org/mail-archive/web/dime/current/msg03598.html

 * I kept this stuff here as the command code allocation was updated
   by RFC5719.. and thus not in RFC3588

10) Section 11.5
 * notes to RFC-Editor added regarding S-NAPTR registries..

11) Appendix B
 * corrected examples to more FC2606-complian

Right.. did I miss something? (except for the deadline a couple of times..)

- JOuni

---

From: Glen Zorn <[email-masked]>
Date: Sun, 21 Aug 2011 16:29:26 +0700

>  * don't know the issue about boilerplate.. anyone?

No a lawyer, but it might not be a bad idea to change it.

...

---

From: jouni korhonen <[email-masked]>
Date: Mon, 22 Aug 2011 15:09:46 +0300

One thing I missed in -27 is the clarification regarding SCTP PPID (thanks for Victor for pointing this out). See 
http://www.ietf.org/mail-archive/web/dime/current/msg04550.html

It was proposed to have two PPIDs, one for plain SCTP and and for SCTP with DTLS. However, just having "MUST be 0" for both PPIDs could also be an alternative.. Any views?

- Jouni

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 22 Aug 2011 14:26:59 +0200

Hi Jouni,

When can we see draft-27 submitted? Just now the I-D is in state 'Dead'
because it was left to expire. 

Thanks and Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> jouni korhonen
> Sent: Monday, August 22, 2011 3:10 PM
> To: [email-masked]
> Subject: Re: [Dime] pre-revision of RFC3588bis-27
> 
> 
> One thing I missed in -27 is the clarification regarding SCTP PPID
> (thanks for Victor for pointing this out). See
> It was proposed to have two PPIDs, one for plain SCTP and and for SCTP
> with DTLS. However, just having "MUST be 0" for both PPIDs could also
> be an alternative.. Any views?
> 
> - Jouni
> 
> 
> > Finally got my lazy *ss up and did a revision -27. Actually now that
> the S-NAPTR registry thing has stabilized it made sense to complete
> RFC3588bis. The intermediate version can be found here:
> > * see
http://www.ietf.org/mail-archive/web/dime/current/msg04671.html
> > * see
http://www.ietf.org/mail-archive/web/dime/current/msg04805.html
> > * see
http://www.ietf.org/mail-archive/web/dime/current/msg04810.html
> > * see
http://www.ietf.org/mail-archive/web/dime/current/msg04808.html
> > * see
http://www.ietf.org/mail-archive/web/dime/current/msg04808.html
> > * see
http://www.ietf.org/mail-archive/web/dime/current/msg04741.html
> > * see
http://www.ietf.org/mail-archive/web/dime/current/msg04616.html
> > * see
http://www.ietf.org/mail-archive/web/dime/current/msg03598.html
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: jouni korhonen <[email-masked]>
Date: Mon, 22 Aug 2011 15:37:00 +0300

Sure.

---

From: <[email-masked]>
Date: Tue, 23 Aug 2011 09:45:32 +0200

Hi All,

Sorry for this late Tuesday comment.

9) Section 11

[Lionel] I'm still not convinced that referring to RFC3588 and pointing
out only the differences in the "bis" is the best way to do.

First, the RFC3588 will become "obsolete" and it would be strange to
still rely on for implementation. Besides, from a reader point of view,
it would be easier to find all the necessary information in the same
document. I think that it is not an issue to replace the reference to
RFC3588 in IANA by the reference to RFC3588bis.

It was done for SCTP, where the SCTP related IANA registries were
updated to reference RFC4960 instead of RFC2960. And we can see the IANA
section of RFC4960 is self-consistent with no reference to RFC2960, even
if existing parameters were initially defined by the RFC2960. Therefore,
I don't see why it would be an issue for RFC3588bis.

Regards,

Lionel

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 23 Aug 2011 10:19:04 +0200

Hi,

I suggest that we get advice Michelle Cotton from IANA on this. 

A possible mid-way solution would be to list in the IANA all allocation
already made in RFC 3588 and then list the changes brought up by
3588bis. 

Regards,

Dan

Of
> [email-masked]
> Sent: Tuesday, August 23, 2011 10:46 AM
> To: [email-masked]; [email-masked]

---

From: Glen Zorn <[email-masked]>
Date: Tue, 23 Aug 2011 15:54:27 +0700

> already made in RFC 3588 and then list the changes brought up by

The major problem IMHO w/the IANA Considerations section as it was was
that it persistently and repeatedly said things like "this document
defines" some value when that clearly was not the case, the the number
had already been defined in RFC 3588.  This rev solves that problem, but
I think in a little bit to lazy a way (& I am a _very_ lazy person, so
for me to say that is somewhat remarkable!).  In any case, I think that
it's neither necessary nor advisable to list all the allocations made in
3588 here; after all, the authoritative reference for existing IANA
allocations is IANA.  However, a reference to the soon-to-be obsolete
predecessor of the soon-to-be RFC seems like a poor idea, as well.
Therefore, I suggest listing only the allocation policies for each type
of number and any new allocations.

...

---

From: jouni korhonen <[email-masked]>
Date: Tue, 23 Aug 2011 12:12:11 +0300

> of number and any new allocations.

That sounds reasonable to me at least.

- Jouni

---

From: Victor Pascual Avila <[email-masked]>
Date: Wed, 24 Aug 2011 13:03:40 +0200

> It was proposed to have two PPIDs, one for plain SCTP and and for SCTP with DTLS. However, just having "MUST be 0" for both PPIDs could also be an alternative.. Any views?

For protocol analyzers it is much easier if specific PPIDs are used.

-Victor

---

From: jouni korhonen <[email-masked]>
Date: Wed, 24 Aug 2011 14:27:59 +0300

Ok. And any proposals for names? "diameter.sctp" and "diameter.dtls" ?
Would using of PPIDs then be MUST or SHOULD?

- Jouni

---

From: Victor Pascual Avila <[email-masked]>
Date: Wed, 24 Aug 2011 15:38:06 +0200

According to RFC4960 Section 14.4 I think SHOULD would be fine

-Victor

-- 
Victor Pascual Ávila

---

From: jouni korhonen <[email-masked]>
Date: Thu, 25 Aug 2011 23:02:31 +0300

Ok. I posted -28 that has "more IANA considerations".. and STCP PPID text+IANA considerations.

Next time someone wants to tweak something, just propose concrete formatted text that can be copy-pasted in ;)

- Jouni

---

From: Glen Zorn <[email-masked]>
Date: Fri, 26 Aug 2011 18:10:36 +0700

> Next time someone wants to tweak something, just propose concrete formatted text that can be copy-pasted in ;)

OK, here you go:

  Diameter AVPs often contain security-sensitive data; for example,
  user passwords and location data, network addresses and cryptographic
  keys.  The Diameter messages containing such AVPs MUST only be sent
  protected via mutually authenticated TLS or IPsec.  In addition, those
  messages SHOULD NOT be sent via intermediate nodes that would
  expose the sensitive data at those nodes except in cases where
  an intermediary is known to be operated as part of the same
  administrative domain as the endpoints so that an ability to
  successfully compromise the intermediary would imply a high
  probability of being able to compromise the endpoints as well.

---

From: jouni korhonen <[email-masked]>
Date: Mon, 29 Aug 2011 10:44:00 +0300

Ok.. and where exactly you want this text to be placed?

- Jouni

---

From: Glen Zorn <[email-masked]>
Date: Mon, 29 Aug 2011 14:46:42 +0700

> Ok.. and where exactly you want this text to be placed?

In the Security Considerations section.

---

From: <[email-masked]>
Date: Mon, 29 Aug 2011 10:41:56 +0200

Blocked in the server last week.

Lionel

-----Message d'origine-----
De : MORAND Lionel RD-CORE-ISS 
Envoyé : mardi 23 août 2011 11:14
À : [email-masked]; [email-masked]
Cc : [email-masked]; [email-masked]; [email-masked]
Objet : RE: [Dime] pre-revision of RFC3588bis-27

Here is an example of the wording used in SCTP, not referring to "this document" but to the protocol itself.

   SCTP defines three registries that IANA maintains:

   -  through definition of additional chunk types,
   -  through definition of additional parameter types, or
   -  through definition of additional cause codes within ERROR chunks.

   SCTP requires that the IANA Port Numbers registry be opened for SCTP
   port registrations, Section 14.5 describes how.  An IESG-appointed
   Expert Reviewer supports IANA in evaluating SCTP port allocation
   requests.

So, wherever the text is placed RFCXXXX or RFCYYYY, it remains valid.
And providing only the allocation policies is a good solution IMHO.

Regards,

Lionel

-----Message d'origine-----
De : Glen Zorn [mailto:[email-masked]] 
Envoyé : mardi 23 août 2011 10:54
À : Romascanu, Dan (Dan)
Cc : MORAND Lionel RD-CORE-ISS; [email-masked]; [email-masked]; Michelle Cotton
Objet : Re: [Dime] pre-revision of RFC3588bis-27

...