Hi Kathleen,

Thanks.  It is unclear to me in your reply as to what the "this" refers to in 
"this was viewed as cleaner".  I.e., does it mean an errata, or AD sponsoring 
your draft?

For, me, if we can get away with doing an errata, i.e., it is sufficient to 
meet the trusts requirements, then I believe that is a better path for the 
following reasons:
(1) Quicker and less work, and I understand that you are under time pressure 
here.
(2) We don't end up with the security template in another RFC.
(3) I'm proposing that the OPS area discussions and refinements to the current 
template text to make it clear about what is expected to be documented.  E.g., 
my reading of the template is that implies that many/most YANG paths or 
subtrees should be documented (and this is seemingly the practice that many WGs 
have been following), but the text in RFC 8407 describing how the template 
should be used is somewhat is different since it refers to documents paths that 
are "especially disruptive if abused" or "especially sensitive information or 
that raise significant privacy concerns".  I.e., the aim is to document the 
exception paths, not giving an overview of all paths/subtrees in the module.  
Hence, I think that this would end up somewhat changing the template text, and 
having one less copy of it seems easier.

Thanks,
Rob


> -----Original Message-----
> From: Kathleen Moriarty <[email protected]>
> Sent: 03 April 2023 21:14
> To: Rob Wilton (rwilton) <[email protected]>
> Cc: Deen, Glenn <[email protected]>; [email protected];
> [email protected]; The IESG <[email protected]>
> Subject: Re: draft-moriarty-yangsecuritytext vs errata
> 
> Hello Rob!
> 
> Thank you for your offer of AD sponsorship. We also reviewed the idea of using
> errata and I think this was viewed as cleaner in that it would be readily
> apparent that the template text could be used with the need for explanation. I
> think (and correct if I left anything out), either works to achieve the 
> objective
> for this since we’re working directly with the IEEE.
> 
> Best regards,
> Kathleen
> 
> Sent from my mobile device
> 
> > On Apr 3, 2023, at 1:30 PM, Rob Wilton (rwilton) <[email protected]> wrote:
> >
> > I'm getting an out-of-office bounce from Glenn, so adding [email protected]
> in the hope that either Kathleen or one of the other trustees is give an 
> answer
> more quickly.
> >
> > Thanks,
> > Rob
> >
> >
> >> -----Original Message-----
> >> From: Rob Wilton (rwilton)
> >> Sent: 03 April 2023 18:19
> >> To: [email protected]; Deen, Glenn
> >> <[email protected]>
> >> Cc: [email protected]; The IESG <[email protected]>
> >> Subject: draft-moriarty-yangsecuritytext vs errata
> >>
> >> Hi Glenn, Kathleen,
> >>
> >> In addition to discussing draft-moriarty-yangsecuritytext in the NETMOD WG
> >> session on Friday (where the conclusion was to go the AD sponsored path), I
> >> also raised this issue with the IESG/IAB at the end of the IETF week, and
> >> someone had the suggestion of filling an errata against the YANG Author
> >> Guidelines (RFC 8407) to add the missing <BEGIN TEMPLATE TEXT> and
> <END
> >> TEMPLATE TEXT> markers to section 3.7.1 of RFC 8407.
> >>
> >> I know that you offered a RFC 8407-bis path, but did you also consider
> whether
> >> adding these markers as errata (which I would regard as being as in-scope
> and
> >> appropriate and could be marked as 'verified')?  If this approach worked
> from
> >> your side, and if there are no objections from the authors or NETMOD, then
> I
> >> was wondering if that could be a more expedient path forward.
> >>
> >> Please let me know if errata would be sufficient from a trust perspective,
> >> otherwise, I'll go the AD sponsored route on Kathleen's draft.
> >>
> >> Regards,
> >> Rob
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to