Subject: Re: [netmod] WG Last Call draft-ietf-netmod-routing-cfg-12 (until 2013-12-20)

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 08 Jan 2014 11:26:21 +0100

Hi,

can we expect any more input on the current revision of the routing draft? If not, I will try to resolve all issues form Martin's review (yes, I think it can be done) and submit a new revision.

Lada

Juergen Schoenwaelder <[email-masked]> writes:

> On Tue, Dec 03, 2013 at 04:16:10PM +0100, Juergen Schoenwaelder wrote:
>> Hi,
>> 
>> I hereby like to start a WG last call for the document "A YANG Data
>> Model for Routing Management":
>> 
>>   http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-12
>> 
>> Please indicate your support by Friday December 20th. We are not only
>> interested in receiving defect reports, we are equally interested in
>> statements of the form:
>> 
>>   "I have reviewed I-D XYZ and I found no issues"
>>   "I have implemented the data model in I-D XYZ"
>>   "I am implementing the data model in I-D XYZ"
>>   "I am considering to implement the data model in I-D XYZ"
>> 
>> This is the 1st WG last call on this document.
>> 
>
> This WG last call did end. We received a detailed review by Martin
> (but I am not sure all issues got resolved) and a review by Lisa. I
> contacted the routing area but have not received anything from them.
> It would not hurt to receive another review as an xmas present...
>
> But assuming Martin's comments can get resolved, I will move this
> document to Benoit's desk since it received significant reviews from
> various routing experts before.
>
> /js
>
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 8 Jan 2014 12:50:42 +0100

> can we expect any more input on the current revision of the routing draft? If not, I will try to resolve all issues form Martin's review (yes, I think it can be done) and submit a new revision.

I think you should resolve Martin's comments and post a new I-D and
once Martin believes the issues have been resolved, I will hand this
over to Benoit. If further reviews come in (even though the WG last
call deadline has passed), we can still consider them IETF WG last
call comments. I am not aware of anyone committed to provide
additional reviews (even though I did notify the routing ADs - but
perhaps things are being reviewed during IETF last call).

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 8 Jan 2014 12:54:26 +0100

> over to Benoit. If further reviews come in (even though the WG last

OK, will do.

Lada

---

From: Jernej Tuljak <[email-masked]>
Date: Wed, 08 Jan 2014 16:21:21 +0100

Not sure if already reported or even if it still applies, but I think I 
might have found a bug in one of them must expressions. In ietf-routing 
module:

/routing/routing-instance/routing-protocols/routing-protocol/connected-ribs/connected-rib/must[1]

must "not(/routing/ribs/rib[name=current()/"
+ "preceding-sibling::connected-rib/"
+ "name and address-family=/routing/ribs/"
+ "rib[name=current()/name]/address-family])"

There is no "//connected-rib/name" node. Perhaps it's a typo for 
"//connected-rib/rib-name" (appears twice in this expression!). Page 40 
of the draft.

Similar at

/routing/ribs/recipient-ribs/recipient-rib/must

(both must expressions). Page 42.

Jernej

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 8 Jan 2014 16:30:06 +0100

Hi Jernej,

yes, I’ve already caught these bugs, they will be corrected in the next revision.

Thanks, Lada

On 08 Jan 2014, at 16:21, Jernej Tuljak <[email-masked]> wrote:

> Not sure if already reported or even if it still applies, but I think I might have found a bug in one of them must expressions. In ietf-routing module:
> 
> There is no "//connected-rib/name" node. Perhaps it's a typo for "//connected-rib/rib-name" (appears twice in this expression!). Page 40 of the draft.
> 
> Similar at
>