Subject: [radext] Barry Leiba's Discuss on draft-ietf-radext-radius-fragmentation-10: (with DISCUSS and COMMENT)

From: "Barry Leiba" <[email-masked]>
Date: Mon, 19 Jan 2015 15:35:29 -0800

Barry Leiba has entered the following ballot position for
draft-ietf-radext-radius-fragmentation-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is just to make sure that the IANA allocations are clear, because I
have some questions about that:

-- Section 14 --

   In particular, this document defines two new RADIUS attributes,
   entitled "Frag-Status" and "Proxy-State-Len" (see section 9),
   assigned values of TBD1 and TBD2 from the Long Extended Space

But these are not defined in Section 9, but in Sections 10.1 and 10.2.

And I see that these are the "Type" values, but where's the allocation of
the "Extended-Type" values that are mentioned in those sections?

Also, there's another "TBA" at the end of Section 14 that points to
Section 4.1, but there is no Section 4.1.  It looks like maybe that's
supposed to be 5.1.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This seems a very well written document, and was easy to read.  In
particular, thanks very much for Section 2: it's one of the best of that
sort of explanation I've seen, and should be a model for other such
specs.

Very minor point: In the diagram in Section 3, I suggest fitting all the
boxed text as in the box that includes "CoA Proxy".  That is, putting
"CoA" on top of "Server" and "client" (why not "Client"?) in the other
boxes makes the separation between the left-side text and the right-side
text just a little clearer.

-- Sections 10.1 and 10.2 --
It's not clear to me how the RFC Editor will know which values to replace
into the four "TBA" items in these sections (two "Type" and two
"Extended-Type" values).  Shouldn't they be distinguished from each
other, to make that clear?  (And see my DISCUSS comments.)

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Tue, 20 Jan 2015 08:43:29 +0100

Hi Barry,

thanks for your comments. See my responses inline, please.

Right. It seems I forgot inserting an <xref> in this place, and 
therefore it didn't get updated when we included the new section 2.

> the "Extended-Type" values that are mentioned in those sections?

Yes. Indeed, this is something the IANA already brought in. Lionel 
Morand provided suggestion of how to solve this issue, that has been 
agreed by us as the best way forward. In particular, the type will be 
fixed to 241, whereas the Extended-Type would be TBDX.

The table would look as follows:

Type       Name                   Length  Meaning
        ----       ----                   ------ -------
241.TBD1   Frag-Status            7       Signals fragmentation
241.TBD2   Proxy-State-Len(*gth*) 7       Indicates the length of the
            received Proxy-State attributes

And the text in section 10.1 and 10.2 would be:

     Type
241 (To be confirmed by IANA)

     Length
7

     Extended-Type
TBDX

> Section 4.1, but there is no Section 4.1.  It looks like maybe that's

Yes. In figure elements it seems that <xref> tags are not possible, and 
I forgot to update these numbers when Section 2 was introduced. The same 
has happened with the table immediately above that one, which points to 
Section 9.1 while it should say 10.1. Both need to be updated.

Thanks.

> text just a little clearer.

We'll do it. Thanks.

> other, to make that clear?  (And see my DISCUSS comments.)

See my comments above. Now TBA is only applied to the 
"Additional-Authorization" value.

Best regards,
Alejandro

---

From: Barry Leiba <[email-masked]>
Date: Tue, 20 Jan 2015 10:06:35 -0500

Thanks for the quick response, Alejandro.  It all sounds good, and I'm
ready to clear the DISCUSS as soon as I see the revised I-D.

Barry

On Tue, Jan 20, 2015 at 2:43 AM, Alejandro Perez Mendez <[email-masked]> wrote:
> Right. It seems I forgot inserting an <xref> in this place, and therefore it
> didn't get updated when we included the new section 2.
>
>
> Yes. Indeed, this is something the IANA already brought in. Lionel Morand
> provided suggestion of how to solve this issue, that has been agreed by us
> as the best way forward. In particular, the type will be fixed to 241,
> whereas the Extended-Type would be TBDX.
>
> Yes. In figure elements it seems that <xref> tags are not possible, and I
> forgot to update these numbers when Section 2 was introduced. The same has
> happened with the table immediately above that one, which points to Section
> 9.1 while it should say 10.1. Both need to be updated.
>
>
>