Re: [OPSAWG] Zaheduzzaman Sarker's Discuss on draft-ietf-opsawg-l2nm-18: (with DISCUSS)

[Zaheduzzaman Sarker <[e-mail]>]

Thanks Med for your prompt reply. Your clarifications were helpful.

Please see inline below

//Zahed


> On 2 Jun 2022, at 11:33, [e-mail] wrote:
> 
> Hi Zahed, 
> 
> Thank you for the review. 
> 
> Please see inline. 
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Zaheduzzaman Sarker via Datatracker <[e-mail] <mailto:[e-mail]>>
>> Envoyé : jeudi 2 juin 2022 10:40
>> À : The IESG <[e-mail] <mailto:[e-mail]>>
>> Cc : [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>;
>> [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
>> Objet : Zaheduzzaman Sarker's Discuss on draft-ietf-opsawg-l2nm-
>> 18: (with DISCUSS)
>> 
>> Zaheduzzaman Sarker has entered the following ballot position for
>> draft-ietf-opsawg-l2nm-18: Discuss
>> 
>> 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/about/groups/iesg/statements/handling-ballot-
>> positions/
>> for more information about how to handle DISCUSS and COMMENT
>> positions.
>> 
>> 
>> The document, along with other ballot positions, can be found
>> here:
>> https://datatracker.ietf.org/doc/draft-ietf-opsawg-l2nm/
>> 
>> 
>> 
>> ------------------------------------------------------------------
>> ----
>> DISCUSS:
>> ------------------------------------------------------------------
>> ----
>> 
>> Thanks for the effort to produce this YANG model, I always
>> fascinate by the
>> work done in creating the YANG models.
>> 
>> I have found inconsistencies in the classification of normative
>> references and
>> informative references, hence, would like to discuss those. Some
>> examples below-
>> 
>> - in the terminology section while [RFC6241], [RFC7950],
>> [RFC8466], [RFC4026],
>> and [RFC8309] are normative references, [RFC8969] and [RFC8340]
>> are not.
> 
> [Med] Only 7950 and 6241 from that list are cited as normative. This is because this is implied by (RFC8407): https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines <https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines> (see the note in that page).
8466 is also in the normative reference.
> 
> For the other RFCs, we are trying to be consistent with previous usages. For ex 
> 
> Take the example of 8340, ** none ** of the very very long of RFCs that cites 8340 is categorizing it as normative: https://datatracker.ietf.org/doc/rfc8340/referencedby/ <https://datatracker.ietf.org/doc/rfc8340/referencedby/>. We can understand that if we look at RFC8407: 
> 
> If YANG tree diagrams are used, then an informative reference to the
> YANG tree diagrams specification MUST be included in the document.
> 
> The majority of RFCs are citing RFC4026 as informative. 
I see your point. For this document while reviewing, I found it very important to understand the terminologies. This might be due to lack of  experience with YANG models on my part. I felt like I can’t digest this doc without understanding those terms and that falls into normative definition to me. As you mentioned majority that doest not mean “all” so I don’t see we should be bothered to put them in the normative section it that helps. I will leave it up to you experts to decide.
> 
> and so on. 
> 
> But
>> clearly this document uses terms defined in those documents and I
>> as a reader
>> had to open those RFCs to understand what the terms are and
>> without that I
>> would not be possible to understand this document.
>> 
>> - sometimes the this document is correctly referring to other
>> documents as
>> normative, as terms or processes are defines there but sometimes
>> it is not. for
>> example -
>> 
>> 'signaling-option':
>> Indicates a set of signaling options that are specific to a given
>> VPN network
>> access, e.g., a CE ID ('ce-id' identifying the CE within the VPN)
>> and a remote
>> CE ID as discussed in Section 2.2.2 of [RFC6624].
> 
> [Med] This is because this is just an example: ", e.g.,"

May be a wrong example to illustrate the case - here is another one

   'l2vpn-bgp':
The service is a Multipoint VPLS that uses a BGP control plane as described in [RFC4761 <https://www.ietf.org/archive/id/draft-ietf-opsawg-l2nm-18.html#RFC4761>] and [RFC6624 <https://www.ietf.org/archive/id/draft-ietf-opsawg-l2nm-18.html#RFC6624>].
RFC4761 is normative and RFC6624 is not. It is very hard for me to see if there is other reasons to make 4761 normative and not 6624.

> 
>> 
>> Now, without understanding what is discussed or defined in RFC6624
>> it was hard
>> for me to understand the node/leaf mentioned in this document.
>> Thus, I felt
>> RFCC6624 should be a normative reference but it was not.
>> 
>> - The reference modules from this document cannot be informative
>> reference, can
>> they? 
> 
> [Med] They can. We are using a classification that is aligned with rfc8407#section-3.9: 
> 
> For every normative reference statement that appears in a module
> contained in the specification that identifies a separate document, a
> corresponding normative reference to that document SHOULD appear in
> the Normative References section. The reference SHOULD correspond to
> the specific document version actually used within the specification.
> If the reference statement identifies an informative reference that
> identifies a separate document, a corresponding informative reference
> to that document MAY appear in the Informative References section.
> 
> For example in section 8.1 it says -
>> 
>> This module references [RFC3032], [RFC4446], [RFC4448],
>> [RFC4553],
>> [RFC4618], [RFC4619], [RFC4717], [RFC4761], [RFC4816],
>> [RFC4842], and
>> [RFC5086].
>> 
>> however, RFC4842 and RFC5086 is informative reference.
> 
> [Med] Which is normal as per the clarification above. 

I see, I haven’t checked if all of the were imported or not. My mistake.