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

[Zaheduzzaman Sarker]

Hi Med,

Thanks for cross checking and addressing the comments.

I think it would be great if authors (and AD) go through the doc to check that 
the references are correct.

I will clear my discuss as I got what I intended with the discuss.

//Zahed


From: mohamed.boucad...@orange.com 
Sent: Thursday, June 2, 2022 2:42 PM
To: Zaheduzzaman Sarker 
Cc: The IESG ; draft-ietf-opsawg-l...@ietf.org 
; opsawg-cha...@ietf.org 
; opsawg@ietf.org ; 
adr...@olddog.co.uk 
Subject: RE: Zaheduzzaman Sarker's Discuss on draft-ietf-opsawg-l2nm-18: (with 
DISCUSS)

Re-,

Please see inline.

Cheers,
Med

De : Zaheduzzaman Sarker 
Envoyé : jeudi 2 juin 2022 12:13
À : BOUCADAIR Mohamed INNOV/NET 
Cc : The IESG ; draft-ietf-opsawg-l...@ietf.org; 
opsawg-cha...@ietf.org; opsawg@ietf.org; adr...@olddog.co.uk
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, 
mohamed.boucad...@orange.com wrote:

Hi Zahed,

Thank you for the review.

Please see inline.

Cheers,
Med


-Message d'origine-
De : Zaheduzzaman Sarker via Datatracker 
mailto:nore...@ietf.org>>
Envoyé : jeudi 2 juin 2022 10:40
À : The IESG mailto:i...@ietf.org>>
Cc : draft-ietf-opsawg-l...@ietf.org; 
opsawg-cha...@ietf.org;
opsawg@ietf.org; 
adr...@olddog.co.uk; 
adr...@olddog.co.uk
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 (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
   Section 5.3.2.2.6 of 
[RFC8466] for 
OAM matters.
==

and
==

See also 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/. 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
documen

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

[mohamed.boucadair]

Re-,

 

Please see inline. 

 

Cheers,

Med

 

De : Zaheduzzaman Sarker  
Envoyé : jeudi 2 juin 2022 12:13
À : BOUCADAIR Mohamed INNOV/NET 
Cc : The IESG ; draft-ietf-opsawg-l...@ietf.org; 
opsawg-cha...@ietf.org; opsawg@ietf.org; adr...@olddog.co.uk
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, mohamed.boucad...@orange.com 
  wrote:

 

Hi Zahed, 

Thank you for the review. 

Please see inline. 

Cheers,
Med




-Message d'origine-
De : Zaheduzzaman Sarker via Datatracker mailto:nore...@ietf.org> >
Envoyé : jeudi 2 juin 2022 10:40
À : The IESG mailto:i...@ietf.org> >
Cc : draft-ietf-opsawg-l...@ietf.org  ; 
opsawg-cha...@ietf.org  ;
opsawg@ietf.org  ; adr...@olddog.co.uk 
 ; adr...@olddog.co.uk  
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 (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

 Section 
5.3.2.2.6 of [RFC8466] for OAM matters.

== 

 

and

==

See also   
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/. 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.,"

 

Ma

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

[Zaheduzzaman Sarker]

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

Please see inline below

//Zahed


> On 2 Jun 2022, at 11:33, mohamed.boucad...@orange.com wrote:
> 
> Hi Zahed, 
> 
> Thank you for the review. 
> 
> Please see inline. 
> 
> Cheers,
> Med
> 
>> -Message d'origine-
>> De : Zaheduzzaman Sarker via Datatracker > >
>> Envoyé : jeudi 2 juin 2022 10:40
>> À : The IESG mailto:i...@ietf.org>>
>> Cc : draft-ietf-opsawg-l...@ietf.org 
>> ; opsawg-cha...@ietf.org 
>> ;
>> opsawg@ietf.org ; adr...@olddog.co.uk 
>> ; adr...@olddog.co.uk 
>> 
>> 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 
>  (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/ 
> . 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 
] and 
[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 t

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

[mohamed.boucadair]

Hi Zahed, 

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Zaheduzzaman Sarker via Datatracker 
> Envoyé : jeudi 2 juin 2022 10:40
> À : The IESG 
> Cc : draft-ietf-opsawg-l...@ietf.org; opsawg-cha...@ietf.org;
> opsawg@ietf.org; adr...@olddog.co.uk; adr...@olddog.co.uk
> 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 (see the note in 
that page).

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/. 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. 

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.,"

> 
> 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 would say, please go through the document and correctly
> categorise all the
> references.
> 
> 
> 
> 


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange de

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

[Zaheduzzaman Sarker via Datatracker]

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. 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].

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? 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.

I would say, please go through the document and correctly categorise all the
references.





___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg