Subject: Re: [radext] Questions about draft-ietf-radext-bigger-packets-03

From: Stefan Winter <[email-masked]>
Date: Thu, 29 Oct 2015 11:33:13 +0100

Hi,

>     Alan> On Sep 21, 2015, at 11:20 AM, Sam Hartman
>     Alan> <[email-masked]> wrote:
>     >> I don't support a stronger recommendation for explicit signaling
>     >> than is present in the draft.
>     >> 
>     >> My rationale is that explicit signaling is very heavy weight for
>     >> client-side libraries.
> 
>     Alan>   I would support a SHOULD for explicit signalling, especially
>     Alan> for proxies.  Failing that, the client SHOULD do signalling at
>     Alan> least once, and then cache the results for some time.
> 
> I think there's already a SHOULD for explicit signaling.

Reading this thread, I'm not sure if both of you agreed. Parts of Alan's
previous message hinted toward at least adding the text about making
RFC2865 home server compatibility part of the things to be evaluated in
this experiment.

So, to clarify: are you happy with the text as-is in rev -04, or are
there pending text changes? If the latter, could either of you suggest
updated text for a new rev?

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

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: Stefan Winter <[email-masked]>
Date: Thu, 29 Oct 2015 12:36:57 +0100

Hello,

>> 5) For "Document quality", I would mention implementations which are
>> known to implement the spec. Are there any? If so, you may want to add
>> an RFC6982 "Implementation Status" section.
> 
>   Uh.... clickety click... I'll take a look at the implementation side of things. :)  But that requires IANA allocation of the packet code and attributes.
> 
>   On that note:  Response-Length is a  2-octet unsigned integer of maximum response length.
> 
>   Can that be changed to be of data type "integer"?   And maybe reference data types?
> 
>   I'll refresh the data types document today.

Unfortunately, RFC7120 does not foresee early allocation of "IESG
Consensus" type allocations.

I wonder what is the document author's preference: publish the document
without waiting for an implementation and the accompanying
Implementation Status section?

Or include such a section, stating that a FreeRADIUS implementation is WIP?

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Alan DeKok <[email-masked]>
Date: Thu, 29 Oct 2015 08:28:24 -0400

> Consensus" type allocations.

  I meant more that the draft should be updated to use "integer" instead of a non-standard data type.

> Or include such a section, stating that a FreeRADIUS implementation is WIP?

  It's hard to have an implementation without an assigned packet code or attribute.  But I think I can put one together with reasonable values... and make sure to *not* ship before the numbers are allocated through IANA.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 29 Oct 2015 09:03:19 -0400

I think it's fine to publish this without  implementation status
section.
Alan, what text change do you want for data types?