Re: [radext] Mirja Kühlewind's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS)

[Mirja Kühlewind <[e-mail]>]

Hi Kathleen,

see below.

On 17.08.2016 16:55, Kathleen Moriarty wrote:
> Hi Mirja,
>
> Hopefully the editors will chime in soon.  One question...
>
> On Wed, Aug 17, 2016 at 10:04 AM, Mirja Kuehlewind <[e-mail]> wrote:
>> Mirja Kühlewind has entered the following ballot position for
>> draft-ietf-radext-ip-port-radius-ext-11: 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 https://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:
>> https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> I fully support Alissa's discussion points and have two more to add:
>>
>> 1) IP-Port-Type TLV only covers UDP, TCP and ICMP. This is not very
>> future-proof: there are other transport protocols that have ports or
>> identifiers that may want to be supported in future. Also it is not clear
>> to me from the document why this information is needed at all in the
>> described use cases. Therefore I see two possible ways forward: Either
>> remove the IP-Port-Type TLV or extend it to also cover other cases.
>
> I don't see why this needs to be future proofed as it is meeting a
> current need and the other protocols may not be using RADIUS.  If they
> do, an update to this document could easily fix that, while keeping
> the document in line with current use cases.  I'm fine with any of
> these 3 responses depending on what the working group thinks is best.

I don't think RADIUS is specified in a way that would only allow it to be 
used for UDP and TCP transmissions. At least PCP is not; see my next 
paragraph in the discuss below.

Further, I don't see a reason for any restrictions here. However, my other 
question is also why is this information needed at all. The use cases in this 
doc gives no explanation why this is needed and what this information is used 
for. If there is no concrete reason to have this information, it should be 
removed.

>
>>
>> Related to this point I would like to mention that RFC6887 is not
>> restricted to UDP/TCP and therefore the following sentence in section 2
>> is not correct:
>> "Note that the definitions of [...] "internal port", [...] "external
>> port" [...] are the same as defined in Port Control Protocol (PCP)
>> [RFC6887]"
>>
>> 2) The IE doctors have provide feedback to IANA that the Information
>> Elements in this doc are underspecified (not confirm with rules in RFC
>> 7013) and should therefore be not registered.  Addressing this feedback
>> could lead to a mayor rewrite of this doc, especially in the relation to
>> the use and definition of transportType and receptively IP-Port-Type TLV,
>> and should therefore be done before a final IESG decision.
>
> If you see the end of the message that went out from IANA, the WG
> might be a little confused on order here.  I agree that the WG needs
> to address these questions from IANA and it should be done prior to
> tomorrow's telechat.  The IANA state shows that an update was posted
> and a review is needed.  It would be helpful for the IESG to see the
> full discussion if any more has happened outside of the emails from
> August 11th.

I replied to this on the other email. I was not talking about the IANA review 
but the expert review that IANA already requested. This review goes back to 
IANA (and Brian confirmed that they have send it) and IANA should forward it 
to the authors. My whole (other) emails was about the fact that this 
communication is not visible to anybody and I just know about it because I 
happen to talked to Brian.

For this document this is actually important because the feedback says that 
the IEs in this doc are underspecified and cannot be registered as they are. 
There is more detailed feedback but my high level summary would be that the 
underspecification could lead to larger changes.

I guess we could ask Brian or IANA to forward this feedback to the IESG list 
to have a more informed discussion here.

Mirja


>
> Thanks,
> Kathleen
>
>>
>>
>>
>>
>
>
>