Subject: Re: [Dime] WGLC for https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4005bis/?

From: "Glen Zorn" <[email-masked]>
Date: Sun, 2 Jan 2011 10:13:35 +0700

Jouni Korhonen [mailto:[email-masked]] writes:

> Hello,
> 
> I did a "chairs'" review of draft-ietf-dime-rfc4005bis-02. 

What is that?  I wasn't aware that the technical (or editorial) opinions of
WG Chairs held any more (or less) weight than anyone else's, at least not by
virtue of their position).

> Here are my
> comments that should be addressed. Most of them are purely editorial,
> some
> might need a bit more fiddling around the I-D.
> 
> ----
> 
> Around introduction Section 1
>  o I would appreciate a short section describing the major changes
> between
>    RFC4005 to RFC4005bis, and what was the reason for such change. In a
>    similar fashion what RFC3588bis has done.

I would appreciate it if that section of RFC3588bis were to be deleted,
since it's pretty much useless to people already familiar with RFC 3588 and
not detailed enough for those who aren't.

> 
> Section 1.1
>  o The terminology/agronym list is not complete. e.g. DNIS, LCP, MTU,
>    FQDN, PAC, LAC, DSCP, OLI, PRI, ISP, TLS are missing.

DNIS is expanded on first usage and used only twice; much the same thing is
true for PRI, ISP and OLI.  MTU, and TLS are on the RFC Editor's list of
"well-known abbreviations"
(http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt).

> 
> Section 1.3
>  o RFC 3588 still mentioned and should be replaced with RFC3588bis
>    reference.

Fine.

> Section 2.3
>  o LCP is never expanded

Fine.

> 
> Section 4.1.1
>  o You might consider lifting this section up one level as it is alone
>    under third level. Maybe just replacing Section 4.1 with Section
> 4.1.1
>    content?
>  o Similar note on Sections 4.4.10.6.1, 4.4.11.4.1

Why destroy the overall organization of the section for the sake of
tidiness?

>  o DSCP is not expanded on the first use.

It's been added to the list in Section 1.1
 
> 
> Sections 4.2.1, 4.5, 4.6
>  o These sections describe flag rules and encryption requirements for
> AVPs.
>    Since the rest of the I-D references to RFC3588bis, which changed the
> use
>    of AVP flag rule presentations (due to lack of end-to-end security
>    specification), the RFC4005bis should follow that. This basically
> means
>    removing MAY, SHLD NOT, Encr columns.

OK

> 
> Section 4.3.1
>  o References missing for IPsec and TLS.

OK.

>  o TLS is not expanded on the first use.

See above.

> 
> Section 4.3.2
>  o Expand ARAP on the first use.

ARAP is listed in Section 1.1

> 
> Section 4.4.10.5.7
>  o IPv6 addresses here should follow the RFC5156 documentation prefix.

OK

> Section 4.4.10.8.1
>  o s/[ARAP]/(ARAP) [ARAP]

Can't find the search string.

> 
> Section 4.4.11.5.1
>  o Is it useful still to mention Vax & Alpha clusters?

Maybe not; OTOH, is it useful to have a set of AVPs dedicated to LAT?

> 
> Section 4.5.8
>  o PAC and LAC are never expanded

OK

> 
> Section 4.5.9
>  o s/decidewitch/decide witch

Fixed.

> 
> Section 5
>  o Could we just reference to RFC3588bis Section 10 on the definition
>    of occurrence symbols? Just to keep them in one place.

???

> 
> Section 6
>  o Since no new IANA considerations are really added this should be
>    made clear in the introductory text.. just to make IANA folks life
>    easier.

Actually, this section has many of the same problems that 3588 bis has;
probably needs to be largely deleted.

> 
> Section 6.5
>  o This will cause a textual update in IANA registry policy, right?

I don't know what you mean.

>    (semantically IETF review and older IETF consensus are equal).
> 
> 
> Note that the I-D depends on the progress of the RFC3588bis due a
> normative
> reference to the RFC3588bis..

That depends upon what you mean by "depends" ;-).  4005bis probably can't be
published as an RFC before 3588bis is, but I don't know why it couldn't be
sent to the RFC Editor first.

...

---

From: Jouni <[email-masked]>
Date: Sun, 2 Jan 2011 22:23:49 +0200

Hello,

Thanks for a quick update!

> not detailed enough for those who aren't.

I still find such rundown useful and I consider myself rather familiar with e.g. 3588. A quick list of what and why. That helps when you need to revisit stuff that happened in past.

> (http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt).

Ok for MTU & TLS.

> Why destroy the overall organization of the section for the sake of

"You might consider".. And I see you did not, which is fine.

It is my personal opinion/matter of taste not having lonely sections at a level deeper than 1.

> Can't find the search string.

My typo. Meant 4.4.10.8. There "..via the AppleTalk Remote Access Protocol [ARAP] They.." could be replaced with "..via the AppleTalk Remote Access Protocol (ARAP) [ARAP]. They.." Since both ARAP acronym and [ARAP] reference has already been introduced in Section 1.1 those may not be needed to done again here. Anyway, the full stop is missing before "They".

>>   of occurrence symbols? Just to keep them in one place.

Basically I meant this:

Old text:

   The following tables present the AVPs used by NAS applications in NAS
   messages and specify in which Diameter messages they may or may not
   be present.  Messages and AVPs defined in the base Diameter protocol
   [I-D.ietf-dime-rfc3588bis] are not described in this document.  Note
   that AVPs that can only be present within a Grouped AVP are not
   represented in this table.

   The tables use the following symbols:

      0    The AVP MUST NOT be present in the message.
      0+   Zero or more instances of the AVP MAY be present in the
           message.
      0-1  Zero or one instance of the AVP MAY be present in the
           message.
      1    Exactly one instance of the AVP MUST be present in the
           message. 

New text:

   The following tables present the AVPs used by NAS applications in NAS
   messages and specify in which Diameter messages they may or may not
   be present.  Messages and AVPs defined in the base Diameter protocol
   [I-D.ietf-dime-rfc3588bis] are not described in this document.  Note
   that AVPs that can only be present within a Grouped AVP are not
   represented in this table.

   The tables use the multiplicity symbols defined in Section 10 of
   [I-D.ietf-dime-rfc3588bis].

> probably needs to be largely deleted.

The new IANA considerations section looks much better now ;)

> I don't know what you mean.

Does not matter anymore with the new polished IANA considerations section.

> That depends upon what you mean by "depends" ;-).  4005bis probably can't be

I was just reminding folks that 4005bis depends on 3588bis and won't get published before 3588bis gets through the pipe. Also non-regular IETFers read the mailing list are not always clear on these dependencies.

- Jouni

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

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 3 Jan 2011 16:02:01 +0700

Jouni [mailto:[email-masked]] writes:

...

> I still find such rundown useful and I consider myself rather familiar
> with e.g. 3588. A quick list of what and why. That helps when you need
> to revisit stuff that happened in past.

I thought that's what diff, list archives & meeting minutes were for...

...

> "You might consider".. And I see you did not, which is fine.

Oh no, I _considered_ it; I just didn't _do_ it ;-)

...

> My typo. Meant 4.4.10.8. There "..via the AppleTalk Remote Access
> Protocol [ARAP] They.." could be replaced with "..via the AppleTalk
> Remote Access Protocol (ARAP) [ARAP]. They.." Since both ARAP acronym
> and [ARAP] reference has already been introduced in Section 1.1 those
> may not be needed to done again here. Anyway, the full stop is missing
> before "They".

Fixed, thanks.

...

>    [I-D.ietf-dime-rfc3588bis].

Well OK, but it seems a little late for that since essentially the same text
occurs in RFC 4072, RFC 5778, RFC 4004...well, almost any document that
defines new Diameter AVPs...

> The new IANA considerations section looks much better now ;)

Thank you ;-)

OK.

...

> I was just reminding folks that 4005bis depends on 3588bis and won't get
> published before 3588bis gets through the pipe. Also non-regular IETFers
> read the mailing list are not always clear on these dependencies.

I see.

...