Re: [icnrg] [irsg] IRSG review of draft-irtf-icnrg-pathsteering

Thanks for the update. The changes look good to me. Once Brian confirms, 
we can start the IRTF Final Poll.

Colin

On 18 May 2023, at 13:44, David R. Oran wrote:

> I just submitted -02 with the changes noted below. Let me know if this 
> is ok and if we can go to final IRSG poll.
>
> Again, many thanks for the helpful review!
>
> DaveO.
>
>
> On 16 May 2023, at 11:13, Colin Perkins wrote:
>
>> Hi Dave, Brian,
>>
>> On 5 May 2023, at 6:22, David R. Oran wrote:
>>> Thanks a ton for the review, Brian!
>>
>> Yes - thanks!
>>
>>> On 4 May 2023, at 14:52, Brian Trammell (IETF) wrote:
>>>
>>>> Greetings,
>>>>
>>>> I’ve reviewed draft-irtf-icnrg-pathsteering for the IRSG.
>>>>
>>>> IMO this document is ready for an IRSG ballot, with nits.
>>>>
>>>> It describes a fairly straightforward way to add path awareness to 
>>>> (path-symmetric) CCNx (as an example of ICN approaches). It has 
>>>> somewhat less stringent security properties than other approaches 
>>>> in the path-aware networking space (e.g. SCION), but this seems 
>>>> perfectly reasonable in the ICN space.
>>>>
>>>> This document could be seen as “glue” between ICNRG and PANRG 
>>>> (note: I’m saying this with my PANRG chair hat off). At the risk 
>>>> of making an obligatory “you didn’t cite the reviewer” 
>>>> comment, which you can feel free to ignore, the document clearly 
>>>> answers the second and third questions (path discovery and 
>>>> selection, here called “steering”) posed by RFC 9217 
>>>> (“Current Open Questions in Path-Aware Networking”) in an ICN 
>>>> context. I find it interesting that no mention was made of the 
>>>> first question (i.e., which properties of a path would a consumer 
>>>> use to make a decision about which paths to use?), aside from a 
>>>> mention in the abstract of potential uses. Given that the document 
>>>> essentially shows how to implement an externally specified design 
>>>> within CCNx, this is possibly reasonable, but might be worth 
>>>> addressing.
>>>>
>>> Good point. We obliquely talk about this in the introductory 
>>> sections about the experimental nature of this specification and 
>>> what experiments it enables, specifically things like network 
>>> instrumentation and multi-path congestion control. Would it make 
>>> sense to add a sentence or two to say that experimenting with paths 
>>> having different properties is also a good goal for research using 
>>> the defined protocol machinery? Happy to do that, and explicitly 
>>> reference RFC9127.
>>
>> I don't think it needs much, but adding a couple of sentences about 
>> this could make sense.
>>
> Done.
>
>>> One nuance compared to other PAN approaches is that this piggybacks 
>>> path discovery on the base ICN data exchange, rather than having a 
>>> separate path advertisement/discovery mechanism. That means when the 
>>> recorded path comes back in an ICN Data message response, the 
>>> properties of the path are known only implicitly to the consumer as 
>>> opposed to being explicitly labeled. That makes the question of what 
>>> properties a consumer uses to choose a path one of 
>>> observation/measurement rather than advance selection based on an 
>>> explicit advertised property (e.g ala SCION). Is this perhaps worth 
>>> mentioning? I’m not sure.
>>
>> I'd think it worth mentioning briefly. It's always good to explicitly 
>> highlight different approaches and the trade-offs they make.
>>
> Done.
>
>> Colin
>>
>>
>>
>>>> I have one editorial nit:
>>>>
>>>> typo “in roder that the forwarders use that path” -> “in 
>>>> order”
>>> Can fix now or wait for RFCed. Will fix if folks think an updated 
>>> draft is appropriate prior to IRSG ballot.
> Fixed now.
>
>>>
>>>>
>>>> Thanks, cheers,
>>>>
>>>> Brian
>>>>
>>>> _______________________________________________
>>>> icnrg mailing list
>>>> icnrg@irtf.org
>>>> https://www.irtf.org/mailman/listinfo/icnrg
>>> aveO
> DaveO