Subject: Re: [radext] #192 (bigger-packets): unclear meaning of "configured categories" of dynamically discovered servers

From: Sam Hartman <[email-masked]>
Date: Sun, 01 Nov 2015 23:47:54 -0500

>>>>> "Stefan" == Stefan Winter <[email-masked]> writes:

    Stefan> Okay... We both agree that this parameter needs to be
    Stefan> configurable. None of us really knows how "categories"
    Stefan> should be defined exactly (nor do we know what will be
    Stefan> useful classification criteria in the field).

    Stefan> I think this is something actual implementations - and their
    Stefan> customer demand - can and will sort out themselves.

I agree with you so far.

    Stefan> The important bit is that it must be configurable in
    Stefan> principle IMHO; and that more than one global default is
    Stefan> something to consider for an implementation. So how about
    Stefan> this as a text proposal:

I also think it's important that this SHOULD  be configurable  along
with everything else that the implementation makes configurable for
dynamic discovery.
That is, I suspect that  the market  will help us decide what the
categories are, but I think we know that for each category an
implementation has, the implementation SHOULD make this parameter
configurable.

    Stefan> OLD:

    Stefan> If dynamic discovery mechanisms are supported, configuration
    Stefan> SHOULD be provided for the maximum size of clients and
    Stefan> servers in each dynamic discovery category.

    Stefan> NEW: If dynamic discovery mechanisms are supported, the
    Stefan> default maximum packet sizes for sending packets SHOULD be
    Stefan> configurable. Implementations MAY choose to allow
    Stefan> configuration of different defaults in different parts of
    Stefan> their dynamic discovery configuration.

Your text loses the should.  I don't find the ambiguity problematic in
the old text, so I prefer the old text.  However, provided that the
process gives my concerns a fair hearing, the new text is not something
I'd object to.  That is, I actively support the old text, but do not
raise an objection if the new text is the result of a reasonable
process.

I do not yet understand your concern with the old text.  It sounds at
some level like you're concerned the old text is ambiguous, but neither
of us seems to believe resolving that ambiguity is important.

--sam

---

From: Stefan Winter <[email-masked]>
Date: Mon, 9 Nov 2015 15:32:14 +0100

Hi,

> implementation has, the implementation SHOULD make this parameter

I'm not very excited about SHOULD vs. MAY. My thinking was that since a
wrong initial configured setting can be fixed with signalling
(Status-Server), it's not overly important. If the SHOULD level is
considered important, I absolutely don't mind the change.

> of us seems to believe resolving that ambiguity is important.

It's probably just a matter of perception. When I read "dynamic
discovery category" I expected that to mean something, while it is not a
defined term at all.

If I were to read this as an implementor, my only reaction to reading
that would probably be "Huh? What am I supposed to do here?".

The purpose of my text suggestion was merely to step back from the
undefined term, and state: be flexible in your configuration defaults if
you can.

Greetings,

Stefan Winter

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

-- 
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: Sam Hartman <[email-masked]>
Date: Mon, 09 Nov 2015 09:37:44 -0500

OK, I get it and would definitely be happy with your text using SHOULD
instead of MAY, and agree that's more clear.
Thanks for working with me to understand your concern.

was the sense of the room last Tuesday compatible with me going forward,
making that change and resubmitting?
(Plus the nit you called out and #196, and possibly one or two other
things I'll go check outstanding issues)

---

From: Stefan Winter <[email-masked]>
Date: Mon, 9 Nov 2015 15:46:12 +0100

Hi,

> things I'll go check outstanding issues)

#196 (2-octet integer for Response-Length) as brought up - the Design
Guidelines states that the draft SHOULD use an unsigned 32 Bit integer
instead.

The text change here, the Response-Length one, aong with the nits sorts
out pretty much all outstanding issues.

And I am not obsessed with #191 - IETF-wide review can flag this if it
is seen as important by non-me persons.

So, with the items above fixed in a new rev, we should be good to go!

Greetings,

Stefan

Tel: +352 424409 1
Fax: +352 422473