Subject: [radext] Adoption of draft-cheng-radext-ip-port-radius-ext-00.txt ?

From: Stefan Winter <[email-masked]>
Date: Wed, 23 Apr 2014 14:47:01 +0200

Hello,

as discussed recently, we believe radext is at a point where old items
are finished and new work can be added to our workload.

There was a good and positive discussion on what is now
draft-cheng-radext-ip-port-radius-ext-00.txt in the London meeting.

BEHAVE (where this work could fit into) is not taking on new work. The
RADEXT charter already allows us to work on RADIUS extensions, so if
there is support for adoption of this work here in our WG, we can take
it on pretty much immediately.

So, this work needs a home and we could be that home if we want to.

This mail starts a two week call for adoption for this draft. Please
reply to this mail indicating whether you are in favour for adoption or
not. Since the discussions in London were of generic nature, and not
directly asking for adoption, there is no default - silence does not
count as acceptance. So don't be silent :-)

The call for adoption ends 7 May 2014.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

---

From: Alan DeKok <[email-masked]>
Date: Wed, 23 Apr 2014 16:36:53 -0400

> count as acceptance. So don't be silent :-)

  I support adoption.

  On a quick review of the document, there are still outstanding issues.
 These issues are around field sizes, data types, etc.  These issues
could be solved by referencing the "data types" draft.  However, that
draft isn't a WG item, and isn't on the charter.

- IP-Port-Type should be "integer" not "one octet"

- IP-Port-Limit TLVs should be "integer", and not "16-bit integer".  I'm
also not sure why this needs a TLV

- IP-Port-Range should be multiple sub-TLVs, instead of one TLV with
binary packed data

- IP-Port-Forwarding-Map has the same comment as above

  The rest of the document seems clear in it's intent, design, and
execution.

  Alan DeKok.