While you are at it, you might like to note
s1.1
/ A NAPT my use /A NAPT may use /
feature siit {
description
......
The translator must support the stateless address mapping
algorithm defined in RFC6052, which is the default behavior.";
reference
"RFC 7915: IP/ICMP Translation Algorithm";
If the algorithm in RFC6052 must be supported, I would expect this to
appear in the Reference clause
list nat64-prefixes {
.....
Destination-based Pref64::/n is discussed in
Section 5.1 of [RFC7050]). For example:
192.0.2.0/24 is mapped to 2001:db8:122:300::/56.
198.51.100.0/24 is mapped to 2001:db8:122::/48.";
reference
"Section 5.1 of RFC7050.";
I see no RFC7050 in the Reference section of the I-D
leaf logging-enable {
....
reference
"Section 2.3 of RFC 6908 and REQ-12 of RFC6888.";
}
I see no RFC6908 in the Reference section of the I-D
Tom Petch
----- Original Message -----
From: <[email protected]>
To: "Joe Clarke" <[email protected]>; "Tim Chown" <[email protected]>
Cc: <[email protected]>; <[email protected]>;
<[email protected]>
Sent: Wednesday, February 07, 2018 8:14 AM
Subject: Re: [OPSAWG] Opsdir early review of
draft-ietf-opsawg-nat-yang-10
> Hi Joe, all,
>
> Thanks. Lets' then go that path.
>
> A new version which addresses the comments from Tim (remove the NPTv6
part + some minor edits) is available at:
>
https://datatracker.ietf.org/doc/draft-ietf-opsawg-nat-yang/?include_tex
t=1
>
> Tim, thank you for identifying this issue at this stage of the
publication process.
>
> One logistic question for the NPTv6 document, though: Should it be
published (1) as draft-ietf-ospawg-* given that its content was part of
the document that was accepted by the WG and that passed the WGLC or (2)
as an individual document that will be handed to the AD together with
draft-ietf-opsawg-nat-yang?
>
> Cheers,
> Med
>
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
