Re: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT)

[Alissa Cooper <[e-mail]>]

> On Apr 8, 2018, at 9:20 AM, Mach Chen <[e-mail]> wrote:
> 
> Hi Tom,
> 
>> -----Original Message-----
>> From: t.petch [mailto:[e-mail]]
>> Sent: Sunday, April 08, 2018 7:42 PM
>> To: Mach Chen <[e-mail]>; Alissa Cooper
>> <[e-mail]>; The IESG <[e-mail]>
>> Cc: [e-mail]; [e-mail]; [e-mail];
>> [e-mail]
>> Subject: Re: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-data-
>> model-10: (with COMMENT)
>> 
>> ---- Original Message -----
>> From: "Mach Chen" <[e-mail]>
>> To: "Alissa Cooper" <[e-mail]>; "The IESG" <[e-mail]>
>> Cc: <[e-mail]>; <[e-mail]>;
>> <[e-mail]>; <[e-mail]>
>> Sent: Sunday, April 08, 2018 9:23 AM
>> 
>>> Hi Alissa,
>>> 
>>> Thanks for your comments!
>>> 
>>> Please see my responses inline...
>>> 
>>>> -----Original Message-----
>>>> From: i2rs [mailto:[e-mail]] On Behalf Of Alissa Cooper
>>>> Sent: Tuesday, April 03, 2018 11:10 PM
>>>> To: The IESG <[e-mail]>
>>>> Cc: [e-mail]; [e-mail];
>> [e-mail];
>>>> [e-mail]
>>>> Subject: [i2rs] Alissa Cooper's No Objection on
>> draft-ietf-i2rs-rib-data-model-10:
>>>> (with COMMENT)
>>>> 
>>>> Alissa Cooper has entered the following ballot position for
>>>> draft-ietf-i2rs-rib-data-model-10: No Objection
>>>> 
>>>> 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-i2rs-rib-data-model/
>>>> 
>>>> 
>>>> 
>>> 
>>> ----------------------------------------------------------------------
>>>> COMMENT:
>>> 
>>> ----------------------------------------------------------------------
>>>> 
>>>> Sec 1.2:
>>>> 
>>>> "YANG tree diagrams provide a concise representation of a YANG
>> module,
>>>>   and SHOULD be included to help readers understand YANG module
>>>>   structure."
>>>> 
>>>> This document does not seem like an appropriate place to have
>> normative
>>>> guidance about this. And if this sentence is removed, I don't see
>> the point of
>>>> including Section 1.2 otherwise. This would also imply deleting the
>> reference to
>>>> I-D.ietf-netmod-yang-tree-diagrams.
>>> 
>>> This results from a YANG doctor review.  I saw it also occurs in other
>> published documents. I personally think it's no harm to keep it, how do you
>> think?
>> 
>> Mach
>> 
>> I think that this is very odd.
>> 
>> YANG guidelines rfc6087bis says
>> "   YANG tree diagrams provide a concise representation of a YANG
>> module,
>>   and SHOULD be included to help readers understand YANG module
>>   structure.  Guidelines on tree diagrams can be found in Section 3 of
>>   [I-D.ietf-netmod-yang-tree-diagrams].
>> "
>> which I think is the correct guidance in the correct place.
>> 
>> A quick look at the recently published RFC8343, RFC8344, RFC8345,
>> RFC8346 contain no text of the kind you suggest so if it occurs in other I-D, then
>> I would regard those other I-D as being in error.
>> 
>> If I look back at a thread from Ebben for a yang doctor review of an earlier
>> version of this I-D, the text I see proposed is
>> 
>> "
>>>   A simplified graphical representation of the data model is used in
>>>   this document.  The meaning of the symbols in these diagrams is
>>>   defined in [I-D.ietf-netmod-yang-tree-diagrams].
>> "
>> which I think is rather different.
> 
> Indeed, my fault, I just checked Ebben's suggestion, it's as above quoted. 
> 
> To Alissa:
> If change to following text, is it OK for you?
> 
> "A simplified graphical representation of the data model is used in
> this document.  The meaning of the symbols in these diagrams is
> defined in [I-D.ietf-netmod-yang-tree-diagrams].”

Yes, thanks.
Alissa

> 
> 
> Best regards,
> Mach
>> 
>> Tom Petch
>> (not a YANG doctor)
>> 
>>>> 
>>>> Sec 2.1: Again here I'm confused about the use of normative
>> language. Why do
>>>> you need to specify normative requirements for what this very
>> document is
>>>> specifying? Or are these supposed to be requirements on
>> implementations?
>>> 
>>> OK, how about this:
>>> 
>>> "...a RIB data model needs to specify a way for an external entity to
>> learn about the functional capabilities of a network device." And
>>> 
>>> " The RIB data model needs a way to expose the nexthop chaining
>> capability supported by a given network device."
>>> 
>>>> 
>>>> Sec 2.5: s/causes/caused/
>>> 
>>> Done
>>> 
>>> The above updates will be reelected in version-11.
>>> 
>>> Thanks,
>>> Mach
>>>> 
>