Subject: [Dime] last review of RFC3588bis before the proto write-up - please comment

From: jouni korhonen <[email-masked]>
Date: Wed, 21 Jul 2010 15:42:06 +0300

Hello all,

[in chair mode]

During the process of writing the Proto Write-up for draft-ietf-dime-rfc3588bis-21.txt I made my last review to the document. I started to think few points that might still need some input from the WG.. sorry.

Purely editorial, could be done during AUTH48

 o Section 5.2 step 2. gives an impression that only NAPTR flag "s" is supported.
   However, this is not the case according to the referenced S-NAPTR RFC3958. We
   did "fix" this in one place i.e. examples in Appendix B. where "a" flags use
   is also illustrated. I would add a note regarding "a" flag to the Section 5.2. 

 o  Section 11.5 should explicitly mention the TLS/TCP port number here (before
    IANA actions marked as TBD like the rest of the document does).

 o (suggested by David L.) In Section 3 add a note that the message length is
   always a multiple of 4.

For the following I must to hear comments _before_ I proceed with the completion of the Proto Write-up:

 o RFC3588bis keeps version as 1 so a RFC3588 node does not really know if it is 
   connecting with another RFC3588 or RFC3588bis node, or vice versa. In Sections
   5.4.1, 5.4.2, 5.5.1, 5.5.2, and 7.2 we actually _change_ the existing command
   ABNFs that are more than just adding optional AVPs or sending less AVPs than
   before (for example adding *[AVP] to a request, which means the receiver may
   see AVPs that are beyond the ABNF it knows). According to the RFC3588bis
   Section 1.3.3 this could mean an allocation of a new command code, which again
   would require an allocation of a new application id for applications using the
   new command.. This would impact backwards compatibility with RFC3588.

   Can we expect then receiving errors like 5008 and 5009 when the other end is
   fully RFC3588 compliant and the other is RFC3588bis compliant? Is this unlikely
   to happen? Can a change to AVP multiplicity in ABNF considered such ABNF change
   that requires a new command code?

- Jouni

---

From: Mark Jones <[email-masked]>
Date: Tue, 27 Jul 2010 14:36:54 -0400

Hi Jouni,

I agree with your proposed editorial changes. See inline for my
comments on the ABNF issues.

>   new command.. This would impact backwards compatibility with RFC3588.

Sections 5.4.1, 5.4.2, 5.5.1 and 5.5.2 added *[ AVP ] to
DPR/DPA/DWR/DWA respectively. This was presumably added for
consistency with the ABNF for other base protocol commands. I view the
change as editorial because RFC3588 also says:

   "An implementation MAY add arbitrary non-mandatory AVPs to any command
   defined in an application, including vendor-specific AVPs without
   needing to define a new application."

Although this text was reworked in 3588bis, an implementation strictly
coded to RFC3588 is not going to barf a 5008 if these commands do
contain extra "non-mandatory" AVPs.

There is no reason to exclude *[AVP] from these commands and the
omission from the ABNF was probably an oversight. I suspect it would
have been approved if raised as an Errata on RFC3588.

Section 7.2 adds two optional AVPs to an ABNF that already had *[ AVP
] so the new format would not result in 5008 or 5009. The Failed-AVP
AVP has the M-bit set but RFC3588 was sufficiently vague on whether
mandatory meant presence or comprehension that a 5008 is unlikely.
Given the descriptions of the missing AVPs, I think these are clearly
oversights and they would have been approved as Errata.

>   to happen?

No and no. Silence from the other stack implementers obviously means
they agree. ;)

>   Can a change to AVP multiplicity in ABNF considered such ABNF change

It is tough to generalize; Did the ABNF contradict normative text?

I think of 3588bis as a collection of Errata. There were several
places in RFC3588 where ambiguity could create interop issues. When
we've hit those, we've been able to consult (and refer partners to)
3588bis in much the same way as we'd consult Errata.

Regards
Mark

---

From: jouni korhonen <[email-masked]>
Date: Thu, 29 Jul 2010 18:39:15 +0300

Hi Mark,

Thanks for the quick reply. Read below..

> comments on the ABNF issues.

Ack.

> contain extra "non-mandatory" AVPs.

Personally I tend to agree. Some implementations I know just ignore excess AVPs outside ABFN with M=0, and continue processing the command like nothing happened. I.e. the assumed behavior from Section 1.2.3 quoted above..  

> ] so the new format would not result in 5008 or 5009. The Failed-AVP

Ok.

> oversights and they would have been approved as Errata.

Right. Actually when reading Section 7 onwards then remaining text makes it quite clear that Failed-AVP is part of the error. Following that I would also add [Experimental-Result] to the Section 7.2 ABNF (as that AVP also has M=1).
> No and no. Silence from the other stack implementers obviously means

Right, hearing more opinions wouldn't make harm though.

> 3588bis in much the same way as we'd consult Errata.

Ok.

- Jouni

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

---

From: jouni korhonen <[email-masked]>
Date: Thu, 29 Jul 2010 18:39:15 +0300

Hi Mark,

Ack.

Ok.

Ok.

- Jouni

---

From: jouni korhonen <[email-masked]>
Date: Thu, 29 Jul 2010 18:51:57 +0300

Hi Mark,

Ack.

Ok.

Ok.

- Jouni

---

From: <[email-masked]>
Date: Thu, 29 Jul 2010 18:28:14 +0200

I agree with Mark understanding, regarding to addition of missing *[AVP] in some commands and decision to keep the version number unchanged.
It would be great if other WG members confirm/contradict these statements.

Cheers,

Lionel 

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De 
> la part de jouni korhonen
> Envoyé : jeudi 29 juillet 2010 17:52
> À : Mark Jones
> Cc : [email-masked]
> Objet : Re: [Dime] last review of RFC3588bis before the proto 
> write-up -please comment
> 
> Hi Mark,
> 
> >> For the following I must to hear comments _before_ I 
> proceed with the completion of the Proto Write-up:
> >> 
> >> o RFC3588bis keeps version as 1 so a RFC3588 node does not really 
> >> know if it is  connecting with another RFC3588 or 
> RFC3588bis node, or vice versa.
> >> In Sections
> >>  5.4.1, 5.4.2, 5.5.1, 5.5.2, and 7.2 we actually _change_ the 
> >> existing command  ABNFs that are more than just adding 
> optional AVPs 
> >> or sending less AVPs than  before (for example adding *[AVP] to a 
> >> request, which means the receiver may  see AVPs that are 
> beyond the 
> >> ABNF it knows). According to the RFC3588bis  Section 1.3.3 
> this could 
> >> mean an allocation of a new command code, which again  
> would require 
> >> an allocation of a new application id for applications 
> using the  new command.. This would impact backwards 
> compatibility with RFC3588.
> >> 
> > 
> >  "An implementation MAY add arbitrary non-mandatory AVPs to any 
> > command  defined in an application, including vendor-specific AVPs 
> > without  needing to define a new application."
> > 
> Personally I tend to agree. Some implementations I know just 
> ignore excess AVPs outside ABFN with M=0, and continue 
> processing the command like nothing happened. I.e. the 
> assumed behavior from Section 1.2.3 quoted above..  
> 
> Right. Actually when reading Section 7 onwards then remaining 
> text makes it quite clear that Failed-AVP is part of the 
> error. Following that I would also add [Experimental-Result] 
> to the Section 7.2 ABNF (as that AVP also has M=1).
> > 
> >>  Can we expect then receiving errors like 5008 and 5009 when the 
> >> other end is  fully RFC3588 compliant and the other is RFC3588bis 
> >> compliant? Is this unlikely  to happen?
> >

---

From: Sebastien Decugis <[email-masked]>
Date: Fri, 30 Jul 2010 12:37:42 +0900

I also agree with these statements.

Beside, it is possible in many cases for a peer to decide whether the
remote peer is RFC3588 or rfc3588bis as a side effect of the new
security mechanism (indicated by the Inband-Security-Id AVP in the
CER/CEA exchange), in case an implementation really needs to know it.

Best regards,
Sebastien.

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