Re: [ippm] John Scudder's Discuss on draft-ietf-ippm-ioam-conf-state-07: (with DISCUSS and COMMENT)

Yep, I have it on my to-do list for ASAP after the IETF-115 week ends. Thanks for the note.

—John

> On Nov 9, 2022, at 12:16 PM, xiao.min2@zte.com.cn wrote:
> 
> 
> Hi John,
> 
> Please note that I've posted -09 revision to address Murray Kucherawy's comments on IANA section. No any other changes. Link as below.
> hhttps://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-conf-state-09
> 
> Best Regards,
> Xiao Min
> Original
> From: 肖敏10093570
> To: jgs@juniper.net <jgs@juniper.net>;
> Cc: ippm-chairs@ietf.org <ippm-chairs@ietf.org>;iesg@ietf.org <iesg@ietf.org>;ippm@ietf.org <ippm@ietf.org>;draft-ietf-ippm-ioam-conf-state@ietf.org <draft-ietf-ippm-ioam-conf-state@ietf.org>;
> Date: 2022年11月07日 09:51
> Subject: Re: [ippm] John Scudder's Discuss on draft-ietf-ippm-ioam-conf-state-07: (with DISCUSS and COMMENT)
> Hi John,
> 
> 
> 
> The I-D submission tool reopens and I've posted -08 revision. Link as below.
> 
> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-conf-state-08
> 
> Much appreciated if you would check it over to see whether your DISCUSS point has been addressed.
> 
> 
> 
> Best Regards,
> 
> Xiao Min
> 
> 
> 
> From: 肖敏10093570
> To: jgs@juniper.net <jgs@juniper.net>;
> Cc: ippm-chairs@ietf.org <ippm-chairs@ietf.org>;iesg@ietf.org <iesg@ietf.org>;ippm@ietf.org <ippm@ietf.org>;draft-ietf-ippm-ioam-conf-state@ietf.org <draft-ietf-ippm-ioam-conf-state@ietf.org>;
> Date: 2022年10月29日 09:02
> Subject: Re: [ippm] John Scudder's Discuss on draft-ietf-ippm-ioam-conf-state-07: (with DISCUSS and COMMENT)
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
> 
> Hi John,
> 
> Thank you for the quick reply.
> Please check inline my response.
> 
> Best Regards,
> Xiao Min
> 
> 
> 
> 
> From: JohnScudder <jgs@juniper.net>
> To: 肖敏10093570;
> Cc: The IESG <iesg@ietf.org>;draft-ietf-ippm-ioam-conf-state@ietf.org <draft-ietf-ippm-ioam-conf-state@ietf.org>;ippm-chairs@ietf.org <ippm-chairs@ietf.org>;ippm@ietf.org <ippm@ietf.org>;marcus.ihlar@ericsson.com <marcus.ihlar@ericsson.com>;
> Date: 2022年10月28日 20:39
> Subject: Re: John Scudder's Discuss on draft-ietf-ippm-ioam-conf-state-07: (with DISCUSS and COMMENT)
> Hi Xiao Min,
> 
> It seems we have converged on most points, more on the one outstanding one below.
> 
> > On Oct 27, 2022, at 11:41 PM, xiao.min2@zte.com.cn wrote:
> >  
> > > - It wasn't clear to me from a quick perusal of RFC 9197 §4.3 whether a request
> > > carrying 0x0000 would elicit replies for all Namespace-IDs (since 0x0000
> > > matches everything) or if it would elicit replies only for capabilities that
> > > have no configured non-default namespace, or are explicitly configured with
> > > namespace 0x0000. Can you either clarify this in the text, or if you think it's
> > > clear from the reference, help me understand what makes it clear?
> > >   
> > > [XM]>>> As I understand it, a request carrying 0x0000 would elicit replies only for capabilities that are explicitly configured with namespace 0x0000. Also note that namespace 0x0000 is the default one, so if there is no any other namespace configured, then all capabilities configured are for namespace 0x0000 by default. Propose to add some text as below.
> > >   
> > > NEW
> > >   
> > >    An IOAM Capabilities Query carrying only the Default-Namespace-ID 0x0000 would elicit replies only for capabilities that are explicitly configured with the Default-Namespace-ID 0x0000.
> >  
> > That helps my understanding, thanks. I wonder if the new text above is exactly what you want or if it would benefit from a little more tuning. Two questions to consider —
> >  
> > - As written the statement doesn’t apply to a query carrying 0x0000 and some other value, say 0x0001. Probably you don’t want to restrict it to only singleton 0x0000 lists? Probably you could fix this by dropping the first instance of “only”, so “… carrying the Default-Namespace-ID”. (Keep the second “only” though.)
> > - Do you really want to restrict it to “explicitly configured”? That might create some ambiguity with regard to capabilities that are implicitly configured with 0x0000, for example, due to a system default. Perhaps drop “explicitly”?
> >  
> > So the possible revision is:
> >  
> >    An IOAM Capabilities Query carrying the Default-Namespace-ID 0x0000 would elicit replies only for capabilities that are configured with the Default-Namespace-ID 0x0000.
> >  
> > [XM]>>> The revision implicates that as long as an IOAM Capabilities Query carries 0x0000, whether the only one or along with other namespace-id, it would elicit replies only for capabilities that are configured with the 0x0000, however that's not the intended behavior, right?
> 
> I see your point. Funnily enough, that was exactly what I was trying to fix about your text, which can ALSO be read that way! Let’s try again.
> 
> NEW:
>    Inclusion of the Default-Namespace-ID 0x0000 elicits replies only for capabilities that are configured with the Default-Namespace-ID 0x0000.
> 
> [XM]>>> The new text you provided looks good to me.
> 
> Thank you again for the productive discussion that make many improvements to this document.
> 
> 
> Thanks,
> 
> —John
> 
> 
> 