Re: [Lsr] Mirja Kühlewind's No Objection on draft-ietf-ospf-xaf-te-06: (with COMMENT)

[Alvaro Retana]

On July 30, 2019 at 11:44:20 AM, Mirja Kühlewind via Datatracker 
(nore...@ietf.org) wrote:

[Speaking as an author.]

Mirja:

Hi!


--
COMMENT:
--

Sec 1: "This document updates [RFC5786] so that a router can also announce
one or more local X-AF addresses using the corresponding Local
Address sub-TLV. Routers using the Node Attribute TLV [RFC5786] can
include non-TE enabled interface addresses in their OSPF TE
advertisements, and also use the same sub-TLVs to carry X-AF
information, facilitating the mapping described above."
I wonder if this text should use normative language (s/can/MAY/) as this is the
part that actually updates RFC5786, however, I didn't check the exact wording
in RFC5786...

We left the Normative language in Section 3, where the actual specification is 
made.

I don’t have a strong opinion as to whether there’s a need for it in the 
Introduction…so I’ll defer to the AD.

Thanks!

Alvaro.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] [IANA #1147720] Early Allocation Request for "Dynamic Flooding on Dense Graphs" - draft-ietf-lsr-dynamic-flooding-03

[Sabrina Tanamal via RT]

Hi all, 

Since this document is requesting early allocations for multiple registries 
with different registration procedures, we'll create separate tickets for the 
allocations and keep you posted on their progress. 

If you have any questions, please let us know.

Best regards, 

Sabrina Tanamal
Senior IANA Services Specialist

On Mon Jul 22 21:06:49 2019, a...@cisco.com wrote:
> The authors of the subject draft have requested early IANA allocation
> of the IANA code-points defined in the draft. The LSR chairs and
> approved the request and are now requesting early allocation.  Alvaro
> (copied) will confirm his approval.
> 
> Thanks,
> Acee Lindem
> LSR Co-Chair

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] AD Review of draft-ietf-isis-yang-isis-cfg-35

[Alvaro Retana]

On June 27, 2019 at 8:36:46 AM, stephane.litkow...@orange.com (
stephane.litkow...@orange.com) wrote:

Stephane:

Hi!

Sorry it took me while to get to your reply.

Thanks for your comments. We are working on updating the document
accordingly.

Please find some replies inline that may require more discussion.

I have stripped the comments that will be fixed in the next revision.

Just leaving some text with answers.

Thanks!

Alvaro.



474 Some parameters like "overload bit" and "route preference" are
not

475 modeled to support a per level configuration.  If an
implementation

476 supports per level configuration for such parameter, this

477 implementation SHOULD augment the current model by adding both

478 level-1 and level-2 containers and SHOULD reuse existing

479 configuration groupings.



[major] "...SHOULD augment the current model by adding both level-1 and
level-2 containers"  What other way would that be done?  I think that
Normative language is not needed in this case.

[SLI] Using YANG there are multiple ways to do things. People may create
new containers, use different namings… and we want to keep the modeling
consistency even in the future augmentations.

Ok…why not use MUST then?  Are there cases where it would be ok to not be
consistent?  IOW, the current wording doesn’t guarantee consistency…




978sequence-number-skipped: This notification is sent when the
system

979receives a PDU with its own system ID and different
contents.  The

980system has to reissue the LSP with a higher sequence number.



[nit] That's the last thing I would have guessed that this action would
have been called...  Maybe it's just me...

[SLI] This is inherited from RFC





982authentication-type-failure: This notification is sent when
the

983system receives a PDU with the wrong authentication type
field.



985authentication-failure: This notification is sent when the
system

986receives a PDU with the wrong authentication information.



[minor] Why do we need both of these?  Given that they both provide the
same information (including the raw PDU), and that
authentication-type-failure is a specific case of receiving "a PDU with the
wrong authentication information"

[SLI] This is inherited from RFC

You used this reply in several places.

Inheriting things from rfc doesn’t mean it is ok…or the best solution…

In either case, most are minor comments, so no big deal.  I just want to
make sure that some of the points were considered.



1239 feature nsr {

1240   description

1241 "Non-Stop-Routing (NSR) support.";

1242 }



[minor] Reference?

[SLI] NSR is a local well known and deployed mechanism. We may enhance the
description if required, however we cannot really provide a reference.

Yes, please do.  See the description in draft-ietf-ospf-yang.




3995 grouping tlv242-router-capabilities {

3996   container router-capabilities {

3997 list router-capability {

3998 leaf flags {

3999   type bits {

4000 bit flooding {

4001   position 0;

4002   description

4003 "If the S bit is set, the IS-IS Router
CAPABILITY

4004  TLV MUST be flooded across the entire routing

4005  domain. If the S bit is clear, the TLV MUST
NOT

4006  be leaked between levels. This bit MUST NOT

4007   be altered during the TLV leaking.";

4008 }



[major] This is a description of the behavior (copied from rfc7981!), not a
description of the field.

[SLI] Yes, but this provides an accurate description on the conditions of
the flag setting.

But this document is not Normative in the behavior above…. If anything,
Normative language should not be used unless making it clear that it is a
direct quote.



4540 notification lsp-too-large {

4541   uses notification-instance-hdr;

4542   uses notification-interface-hdr;



4544   leaf pdu-size {

4545 type uint32;

4546 description "Size of the LSP PDU";

4547   }

4548   leaf lsp-id {

4549 type lsp-id;

4550 description "LSP ID";



4552   }

4553   description

4554 "This notification is sent when we attempt to propagate

4555  an LSP that is larger than the dataLinkBlockSize for the

4556  circuit.  The notification generation must be throttled

4557  with at least 5 seconds between successive

4558  notifications.";

4559 }




[major] "must be throttled"  Why is this text not Normative?  It seems to
me that throttling is a good practice...in 

Re: [Lsr] WGLC: draft-ietf-isis-yang-isis-cfg (and remaining IPR replies)

[Derek Yeung]

I am not aware of any IPR related to the document too.

Derek Yeung
de...@arrcus.com
Main: 408.884.1965
 

 
2077 Gateway Place, Suite 400
San Jose, CA.  95110
 
The contents of this message, together with any attachments, are intended only 
for the use of the individual or entity to which they are addressed and may 
contain information that is confidential and proprietary to Arrcus. If you are 
not the intended recipient, you are hereby notified that any dissemination, 
distribution, or copying of this message, or any attachment, is strictly 
prohibited. If you have received this message in error, please notify the 
original sender immediately by telephone or by return E-mail and delete this 
message, along with any attachments, from your computer. Thank you.
 

On 7/30/19, 1:45 AM, "Ladislav Lhotka"  wrote:

I am also not aware of any IPR related to the document.

Lada

On Tue, 2019-07-30 at 08:06 +, stephane.litkow...@orange.com wrote:
> I'm not aware of any IPR related to this document.
> 
> -Original Message-
> From: Christian Hopps [mailto:cho...@chopps.org] 
> Sent: Monday, July 29, 2019 19:22
> To: lsr@ietf.org
> Cc: Christian Hopps; lsr-cha...@ietf.org; lsr-...@ietf.org; 
> draft-ietf-isis-yang-isis-...@ietf.org
> Subject: WGLC: draft-ietf-isis-yang-isis-cfg (and remaining IPR replies)
> 
> Hi Folks,
> 
> 
> As mentioned in the meeting in Montreal, due to mixup (IPR call but no 
WGLC)
> the IS-IS yang module was submitted to the IESG prior to a WGLC being 
done. We
> are belated doing a WGLC on this document now. Please voice any 
objections to
> the continued progression of this document. Prior to objecting though 
please
> do review any comments received during IESG reviews.
> 
> https://datatracker.ietf.org/doc/draft-ietf-isis-yang-isis-cfg/
> 
> The WGLC will complete in 2 weeks on Aug 12th.
> 
> Authors (Stephane, Derek and Jeffery),
> 
> Please indicate if you are aware of any IPR related to this document in a
> reply to the mailing list (already received from Acee and Ladislav).
> 
> 
> Thanks,
> Chris & Acee.
> 
> 
__
> ___
> 
> 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 decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and 
delete
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Mirja Kühlewind's No Objection on draft-ietf-ospf-xaf-te-06: (with COMMENT)

[Mirja Kühlewind via Datatracker]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-ospf-xaf-te-06: 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-ospf-xaf-te/



--
COMMENT:
--

Sec 1: "This document updates [RFC5786] so that a router can also announce
   one or more local X-AF addresses using the corresponding Local
   Address sub-TLV.  Routers using the Node Attribute TLV [RFC5786] can
   include non-TE enabled interface addresses in their OSPF TE
   advertisements, and also use the same sub-TLVs to carry X-AF
   information, facilitating the mapping described above."
I wonder if this text should use normative language (s/can/MAY/) as this is the
part that actually updates RFC5786, however, I didn't check the exact wording
in RFC5786...


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WGLC: draft-ietf-isis-yang-isis-cfg (and remaining IPR replies)

[Ladislav Lhotka]

I am also not aware of any IPR related to the document.

Lada

On Tue, 2019-07-30 at 08:06 +, stephane.litkow...@orange.com wrote:
> I'm not aware of any IPR related to this document.
> 
> -Original Message-
> From: Christian Hopps [mailto:cho...@chopps.org] 
> Sent: Monday, July 29, 2019 19:22
> To: lsr@ietf.org
> Cc: Christian Hopps; lsr-cha...@ietf.org; lsr-...@ietf.org; 
> draft-ietf-isis-yang-isis-...@ietf.org
> Subject: WGLC: draft-ietf-isis-yang-isis-cfg (and remaining IPR replies)
> 
> Hi Folks,
> 
> 
> As mentioned in the meeting in Montreal, due to mixup (IPR call but no WGLC)
> the IS-IS yang module was submitted to the IESG prior to a WGLC being done. We
> are belated doing a WGLC on this document now. Please voice any objections to
> the continued progression of this document. Prior to objecting though please
> do review any comments received during IESG reviews.
> 
> https://datatracker.ietf.org/doc/draft-ietf-isis-yang-isis-cfg/
> 
> The WGLC will complete in 2 weeks on Aug 12th.
> 
> Authors (Stephane, Derek and Jeffery),
> 
> Please indicate if you are aware of any IPR related to this document in a
> reply to the mailing list (already received from Acee and Ladislav).
> 
> 
> Thanks,
> Chris & Acee.
> 
> __
> ___
> 
> 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 decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WGLC: draft-ietf-isis-yang-isis-cfg (and remaining IPR replies)

[stephane.litkowski]

I'm not aware of any IPR related to this document.

-Original Message-
From: Christian Hopps [mailto:cho...@chopps.org] 
Sent: Monday, July 29, 2019 19:22
To: lsr@ietf.org
Cc: Christian Hopps; lsr-cha...@ietf.org; lsr-...@ietf.org; 
draft-ietf-isis-yang-isis-...@ietf.org
Subject: WGLC: draft-ietf-isis-yang-isis-cfg (and remaining IPR replies)

Hi Folks,


As mentioned in the meeting in Montreal, due to mixup (IPR call but no WGLC) 
the IS-IS yang module was submitted to the IESG prior to a WGLC being done. We 
are belated doing a WGLC on this document now. Please voice any objections to 
the continued progression of this document. Prior to objecting though please do 
review any comments received during IESG reviews.

https://datatracker.ietf.org/doc/draft-ietf-isis-yang-isis-cfg/

The WGLC will complete in 2 weeks on Aug 12th.

Authors (Stephane, Derek and Jeffery),

Please indicate if you are aware of any IPR related to this document in a reply 
to the mailing list (already received from Acee and Ladislav).


Thanks,
Chris & Acee.

_

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 decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr