Subject: Re: [radext] Extended IDs

From: Stefan Winter <[email-masked]>
Date: Tue, 28 Nov 2017 14:54:32 +0100

Hello,

> thanks all for raising the awareness of these two drafts.
>
>
> I think it would be good if all remaining readers of this list who care
> enough now take some time to read both drafts and make up their mind on
> what the preferred approach is.
>
>
> In approx. two weeks' time I will start a call for adoption on both
> drafts, and hopefully there are enough responses to make the exercise
> meaningful. If so, the one with more votes wins.

Now that was a relaxed "two weeks" delay. My apologies, I've been on and
off work for a while, with substantial backlogs.

This email starts a two week call for adoption of at most one of the
following two drafts:

* draft-chen-radext-identifier-attr-02
* draft-dekok-radext-request-authenticator-02

Since the two drafts treat the same topic, at most one can be selected
to serve as the basis for future work.

In your reply to this call for adoption, please indicate which of the
two drafts you think should be adopted. You can of course also indicate
that none of the two are fit for purpose. The only thing you really
shouldn't do is to vote for both; that wouldn't help the discussion move on.

Please reply by 12 dec 2017 2400 UTC.

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: Alan DeKok <[email-masked]>
Date: Tue, 28 Nov 2017 11:16:01 -0500

> shouldn't do is to vote for both; that wouldn't help the discussion move on.

  I prefer draft-dekok-radext-request-authenticator-02

  If the WG decides to use draft-chen-radext-identifier-attr-02, then I believe it needs significant changes before it's ready for publication:

- use of "ad hoc" complex data type violates RFC 6929 Section 6.3

- the negotiation can be simplified with no loss of functionality.  See my draft for examples.

- there is minimal discussion as to how this affects proxies, TCP, UDP, etc. 

- there is minimal discussion of inter-operability considerations with existing RADIUS solutions

- there are few guidelines for implementors

  While some WG members may prefer the technical solution in draft-chen-radext-identifier-attr-02, I think everyone can agree that the other proposal has these issues exhaustively enumerated and discussed.

  Alan DeKok.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 29 Nov 2017 16:57:24 +0000

I support adoption of draft-chen-radext-identifier-attr-02. I think this
is a much more straight-forward approach to solve the problem without
overloading RADIUS authentication mechanisms.
Thanks,
Acee

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 1 Dec 2017 02:02:14 +0000

I generally don't like overloading a field with different semantics,
because if one of the semantics needs to change in the future, the dependency
on the other semantic will complicate the change.
For that reason, I prefer draft-chen-radext-identifier-attr-02.
I do like some of the detailed discussion of the issues in
draft-dekok-radext-request-authenticator-02.
I think the final document should include some of these discussions.

Thanks,
Jakob

-----Original Message-----

> <0x8A39DC66.asc>_______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext