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

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