Hi Med,
> On 6 Feb 2018, at 09:02, [email protected] wrote:
>
> Hi Tim,
>
> Thank you for the review.
>
> Please see inline.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : Tim Chown [mailto:[email protected]]
>> Envoyé : lundi 5 février 2018 20:07
>> À : [email protected]
>> Cc : [email protected]; [email protected]
>> Objet : Opsdir early review of draft-ietf-opsawg-nat-yang-10
>>
>> Reviewer: Tim Chown
>> Review result: Has Nits
>>
>> I have reviewed this document as part of the Operational directorate's
>> ongoing
>> effort to review all IETF documents being processed by the IESG. These
>> comments were written with the intent of improving the operational aspects of
>> the IETF drafts. Comments that are not addressed in last call may be included
>> in AD reviews during the IESG review. Document editors and WG chairs should
>> treat these comments just like any other last call comments.
>>
>> This document defines a YANG model for a wide variety of NAT functions,
>> including NAT44, NAT64, CLAT, SIIT and NPT66.
>>
>> The document is generally well written, and structured appropriately. There
>> are some very minor grammatical errors. Appropriate documentation prefixes
>> are
>> used in the Appendix of examples.
>>
>> I believe the document is Ready for publication, with Nits.
>>
>> Note: I am not a YANG doctor; I see that a separate YANG doctor review was
>> performed, and I assume that review has covered Section 3.
>>
>> General comment:
>>
>> This document is targeted to Standards Track, yet defines a YANG model for an
>> Experimental protocol, NPT66; is that acceptable? (I don't know, but I feel
>> the question needs to be raised, given also the text of
>> draft-ietf-v6ops-ula-usage-considerations-02.)
>
> [Med] The document defines NPTv6 as a "feature". It does not recommend nor
> argue against the use of NPTv6 per se.
>
> FWIW, I'm aware of one Standards Track RFC which lists NPTv6 as one of its
> deployment scenarios: RFC6887.
>
> ==
> PCP can be used in various deployment scenarios, including:
> ..
>
> o IPv6-to-IPv6 Network Prefix Translation (NPTv6) [RFC6296]
> ==
Well, I raise the question for consideration by the IESG; while there's a
precedent here - and probably elsewhere - it feels odd having a Standards Track
document supporting an Experimental one.
Could the NPTv6 definitions be extracted to a separate RFC, as you have done
with some other elements, or are they shared with Standards Track mechanisms?
>> Nits:
>>
>> p.4 - I think an Internal Host doesn't really "solicit" a NAT capability;
>> that
>> implies some messaging between the host and the NAT. Perhaps say "need to
>> use",
>> or something else.
>
> [Med] Works for me. Thanks.
>
>>
>> Appendix - it would perhaps be easier for the reader if the same
>> documentation
>> prefixes were used to refer to internal and external networks throughout the
>> examples, though this is only a minor style point.
>
> [Med] I updated where it makes sense.
>
>>
>> Section A.11 - the ULA prefixes used here are not (or very unlikely to be!)
>> true ULAs with randomised prefixes. Again, a style point. Perhaps some
>> documentation ULAs need to be defined elsewhere.
>
> [Med] As explicitly stated in titles ("Example of NPTv6 (RFC6296)" and
> "Connecting two Peer Networks (RFC6296)"), these examples are extracted from
> RFC6296. We are re-using the same prefixes as those in 6296-examples.
Again, it feels odd though looking at them. The alternative is to use a true
ULA prefix (roll the dice!).
Tim
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
