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

[[e-mail]]

Re-,

 

Please see inline. 

 

Cheers,

Med

 

De : Zaheduzzaman Sarker <[e-mail]> 
Envoyé : jeudi 2 juin 2022 12:13
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Objet : Re: Zaheduzzaman Sarker's Discuss on draft-ietf-opsawg-l2nm-18: (with DISCUSS)

 

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

 

Please see inline below

 

//Zahed

 





On 2 Jun 2022, at 11:33, [e-mail] <mailto:[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.

 

[Med] Yes, you are right. I have the context recovered now for 8466. This was listed as normative as we don’t reiterate OAM and color type usage in the L2NM and point to 8466.

 

==

   As shown in Figure 17, the L2NM inherits the same structure as in

    <https://datatracker.ietf.org/doc/html/rfc8466#section-5.3.2.2.6> Section 5.3.2.2.6 of [RFC8466] for OAM matters.

== 

 

and

==

See also  <https://datatracker.ietf.org/doc/html/rfc8466#section-5.10.2.1> Section 5.10.2.1 of [RFC8466] for more
    discussion of QoS classification including the use of color types.

===


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.



[Med] Noted, thanks.


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 [ <https://www.ietf.org/archive/id/draft-ietf-opsawg-l2nm-18.html#RFC4761> RFC4761] and [ <https://www.ietf.org/archive/id/draft-ietf-opsawg-l2nm-18.html#RFC6624> 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.

 

[Med] For this one I think that what happened is that we trusted the classification made in RFC8466, which had the same wording as the one you quoted: 

 

==

   o  Multipoint VPLSs that use a BGP control plane as described in

      [RFC4761] and [RFC6624].

==

 

I moved this one to normative, especially after re-reading this part: 

 

==

   Remote CEs that are entitled to connect to the same VPN should fit
   with the CE range ('ce-range') as discussed in  <https://datatracker.ietf.org/doc/html/rfc6624#section-2.2.3> Section 2.2.3 of
   [RFC6624] <https://datatracker.ietf.org/doc/html/rfc6624#section-2.2.3> . 'pw-encapsulation-type' is used to control the pseudowire
   encapsulation type (Section <https://datatracker.ietf.org/doc/html/rfc6624#section-3>  3 of [RFC6624]). 

== 


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.