Re: Last Call: (The Internet Numbers Registry System) to Informational RFC

[SM]

At 13:45 12-05-2013, Tom Vest wrote:
I certainly did not intend to misrepresent your position. But given 
the fact that the
 "part of a message" that you reproduced was offered in response to 
doubts that you yourself raised about the points covered therein 
(esp. "operational need"), what is your position, exactly? As David 
said, "to date" the communities have established policies that are 
broadly informed by the practical implications of the finitude and 
uniqueness constraints on address resource management. However, to 
conclude based on past observations that such will always be true 
would be tantamount to claiming that management of those 
constraints is assured by the operation of (unspecified 
self-executing, self-sustaining) principles. Based on your views as 
expressed in/around draft-moonesamy-rfc2050-historic-00, it's 
pretty clear that you don't see any durable, much less "timeless" 
principles embodied therein -- but that only makes your position on 
these matters all the more ambiguous.


I prefer to keep draft-housley-rfc2050bis-01 separate from other 
drafts to keep matters simple.  My position is that it is better to 
work towards consensus.



Perhaps it would help if you would answer the following clarifying questions:

1. Is it your position that some other force or principle(s) outside 
of the general mechanisms/practices documented in RFC2050 (and 
potentially, RFC2050-bis) guarantees that IETF-defined addressing 
protocols will "just work" as designed, in perpetuity, and thus the 
informational codification of matters related to the management of 
finitude and uniqueness constraints is at best unnecessary, at worst 
counterproductive? If so, what are those unnamed forces/principles, exactly?


2. Is it your position that, if the traditional "communities 
interested in IP addressing" one day elect to adopt policies that 
make it impossible for IETF addressing protocols to fulfill even the 
basic "just work" test, then from the "IETF view"  that should be 
regarded as a perfectly appropriate and acceptable outcome?


I don't have an opinion about questions (1) or (2).

Could you please clarify which passages about Internet address 
architecture you are suggesting are sufficient to make the sections 
about distribution and uniqueness constraints unnecessary?


The comment was in a reply to a comment from another person.  There 
wasn't any mention of "distribution and uniqueness constraints" in 
the quoted text.


Regards,
-sm  

MalcolmBETTS90013533 is out of the office.

[Malcolm . BETTS]

I will be out of the office starting  10/05/2013 and will not return until
20/05/2013.

I will not have access to email, I will respond to your message when I
return on May 20th.

Gen-ART LC Review of draft-ietf-forces-interop-07

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-forces-interop-07
Reviewer: Ben Campbell
Review Date: 2013-05-13
IETF LC End Date: 2013-05-13
IESG Telechat date: 

Summary: This draft is almost ready for publication as an informational RFC. I 
have a few minor questions and editorial comments that may be worth considering 
prior to publication.

*** Major issues:

None.

*** Minor issues:

-- The draft mentions a couple of instances of tests that failed because of an 
incorrect implementation or differing encapsulation formats. Does this suggest 
that the specifications should be clarified? In particular, in the case of 
encapsulation format mismatch, should the specs include stronger requirements 
to be able to receive all encapsulation formats? Or should the number of 
options be reduced?

-- I have a mild concern that the use of origin country names for each 
implementation could confuse readers into thinking that the countries 
themselves officially participated, rather than organizations from each country.


-- section 4.4, last paragraph:

The text says that since the mentioned failures were likely the result of bugs, 
it doesn't indicate an interoperability problem in the specs. I have to point 
out that, it also doesn't prove interoperability in both directions for the 
particular test. It would also be worth commenting on whether the probably bugs 
were programming errors rather than misunderstandings of the specification.


*** Nits/editorial comments:

-- The draft uses inconsistent verb tense throughout. I found this a bit 
confusing, as I assume the draft talks entirely about tests that have already 
occurred.

-- IDNits points out that you have several references without explicit 
citations. I see that you called the references out by name in the text, but it 
would be better to include the citations.

-- Section 1, paragraph 6:

Please expand abbreviations on first mention.

-- Section 1.1:

Please expand FE on first mention.

-- section 2.2.2, paragraph 1: "... from China and Japan implementations..."

Missing "the".

Is it possible to add a reference for details on the Smartbits testing machine?

-- Figure 2:

Do you really want to publish the IP addresses used in an RFC? RFCs live 
forever...

-- Section 2.2.2, paragraph after figure 2: 

First sentence does not parse.


-- Figure 3:

The figure has some formatting issues, at least in the PDF version. Also, is it 
possible to avoid splitting the figure across the page break?

-- section 3.2, paragraph 3: "Because of system deficiency to deploy IPSec over 
TML in Greece,..."

Phrase doesn't parse.

-- section 3.2, paragraph 4: "... over IPSec channel."

Missing "the".

"...to have established..."

to establish.

-- section 4 and subsections:

It seems like some of the test descriptions in 4.X may be redundant to the 
previous scenario descriptions.

-- section 4.1, notes on 28 and 29:

Sentence does not parse.

... notes on 30 and 31:

Missing articles.

-- section 5.1, last paragraph in list item "2.": "The interoperability test 
witnessed that..."

The test _showed_...   [or the _testers_ witnessed...]

-- section 9:

It would be worth mentioning that you explicitly tested for IPSec support.


 

Re: Gen-art telechat review: draft-ietf-6renum-gap-analysis-06.txt (updated for -07)

[Tim Chown]

Yes, thanks all - I think we're nearly there…

Tim

On 13 May 2013, at 02:58, Liubing (Leo)  wrote:

> Hi, Robert
> 
> Your careful review and comments really helped improving the document a lot.
> Many thanks to you.
> 
> All the best,
> Bing
> 
>> -Original Message-
>> From: Robert Sparks [mailto:rjspa...@nostrum.com]
>> Sent: Friday, May 10, 2013 11:13 PM
>> To: Liubing (Leo)
>> Cc: re...@ietf.org; draft-ietf-6renum-gap-analy...@tools.ietf.org;
>> gen-...@ietf.org; ietf@ietf.org
>> Subject: Re: Gen-art telechat review: draft-ietf-6renum-gap-analysis-06.txt
>> (updated for -07)
>> 
>> Thanks Bing -
>> 
>> The updates make the document better, and I appreciate the resolution of
>> referencing Tim's expired draft.
>> I think you've addressed all my comments except for the one on section
>> 5.1, but that's ok.
>> 
>> For completeness and ease on the ADs, here's an updated summary:
>> 
>> Document: draft-ietf-6renum-gap-analysis-05.txt
>> Reviewer: Robert Sparks
>> Review Date: May 10, 2013
>> IETF LC End Date: April 10, 2013
>> IESG Telechat date: May 16, 2013
>> 
>> Summary: Ready
>> 
>> 
>> 
>> On 5/2/13 6:02 AM, Liubing (Leo) wrote:
>>> Hi, Robert
>>> 
>>> Thanks a lot for your continuous careful review.
>>> Please see replies inline.
>>> 
 -Original Message-
 From: Robert Sparks [mailto:rjspa...@nostrum.com]
 Sent: Wednesday, May 01, 2013 12:33 AM
 To: re...@ietf.org; draft-ietf-6renum-gap-analy...@tools.ietf.org
 Cc: gen-...@ietf.org; ietf@ietf.org
 Subject: Gen-art telechat review: draft-ietf-6renum-gap-analysis-06.txt
 
 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at
 < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
 
 Please wait for direction from your document shepherd
 or AD before posting a new version of the draft.
 
 Document: draft-ietf-6renum-gap-analysis-05.txt
 Reviewer: Robert Sparks
 Review Date: April 1, 2013
 IETF LC End Date: April 10, 2013
 IESG Telechat date: May 16, 2013
 
 Summary: Ready with nits (that border on minor issues)
 
 This update improved the readability significantly, and addressed my
 major concern about being able to build a list of the gaps. Thank you.
 
 There are a few issues from my last call review that are still not
 addressed.
 I have left the classification of minor issue vs nits the same as the
 original review to make referring to the earlier review easier,
 but please consider all of these Nits. The IESG will need to decide
 whether to escalate them.
 
 I've trimmed away the points that were addressed.
 
 On 4/1/13 3:46 PM, Robert Sparks wrote:
> --
> Minor issues:
> 
> The document currently references
> draft-chown-v6ops-renumber-thinkabout several times.
> That document is long expired (2006). It would be better to simply
> restate what is
> important from that document here and reference it only once in the
> acknowlegements
> rather than send the reader off to read it.
 This version still references that long expired draft. There was also
 conversation on apps-discuss
 about making that reference normative. IMHO, this is not the right way
 to treat the RFC series, and
 strongly encourage moving the text that you want to reference into
 something that will
 become an RFC.
>>> [Bing] Maybe Brian's suggestion of putting some texts into an appendix is a
>> good way. We'll discuss this problem when make the next time update.
>>> 
> Should section 8 belong to some other document? It looks like
> operational renumbering
> advice/considerations, but doesn't seem to be exploring renumbering
> gaps, except for
> the very short section 8.2 which says "we need a better mechanism"
> without much explanation.
 Afaict, this wasn't addressed at all. In particular, "we need a better
 mechanism" is still all that
 section 8.2 says.
>>> [Bing] Sorry for leaving it out. Will do in next update.
>>> 
> Section 5.1, first bullet. The list below "the impact of ambiguous M/O
> flags" says things like
> "there is no standard" and "it is unspecified". I think you are trying
> to say that there is
> ambiguity in what's written, not that nothing's written. This entire
> list would benefit from
> being recast in terms of what needs to be done (what are the gaps?).
 This text remains unmodified.
>>> [Bing] We made revision focusing on explaining "what are the gaps", but
>> the texts change was omitted, will do in next update.
>>> 
> --
> Nits/editorial comments:
> 
> There are a few sentences ending with "etc." in the document. Please
> consider deleting the
> word from the list - it doesn't help each sentence make its point.
 There were some changes, but mostly t

RE: Gen-art telechat review: draft-ietf-6renum-gap-analysis-06.txt (updated for -07)

[Liubing (Leo)]

Hi, Robert

Your careful review and comments really helped improving the document a lot.
Many thanks to you.

All the best,
Bing

> -Original Message-
> From: Robert Sparks [mailto:rjspa...@nostrum.com]
> Sent: Friday, May 10, 2013 11:13 PM
> To: Liubing (Leo)
> Cc: re...@ietf.org; draft-ietf-6renum-gap-analy...@tools.ietf.org;
> gen-...@ietf.org; ietf@ietf.org
> Subject: Re: Gen-art telechat review: draft-ietf-6renum-gap-analysis-06.txt
> (updated for -07)
> 
> Thanks Bing -
> 
> The updates make the document better, and I appreciate the resolution of
> referencing Tim's expired draft.
> I think you've addressed all my comments except for the one on section
> 5.1, but that's ok.
> 
> For completeness and ease on the ADs, here's an updated summary:
> 
> Document: draft-ietf-6renum-gap-analysis-05.txt
> Reviewer: Robert Sparks
> Review Date: May 10, 2013
> IETF LC End Date: April 10, 2013
> IESG Telechat date: May 16, 2013
> 
> Summary: Ready
> 
> 
> 
> On 5/2/13 6:02 AM, Liubing (Leo) wrote:
> > Hi, Robert
> >
> > Thanks a lot for your continuous careful review.
> > Please see replies inline.
> >
> >> -Original Message-
> >> From: Robert Sparks [mailto:rjspa...@nostrum.com]
> >> Sent: Wednesday, May 01, 2013 12:33 AM
> >> To: re...@ietf.org; draft-ietf-6renum-gap-analy...@tools.ietf.org
> >> Cc: gen-...@ietf.org; ietf@ietf.org
> >> Subject: Gen-art telechat review: draft-ietf-6renum-gap-analysis-06.txt
> >>
> >> I am the assigned Gen-ART reviewer for this draft. For background on
> >> Gen-ART, please see the FAQ at
> >> < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> >>
> >> Please wait for direction from your document shepherd
> >> or AD before posting a new version of the draft.
> >>
> >> Document: draft-ietf-6renum-gap-analysis-05.txt
> >> Reviewer: Robert Sparks
> >> Review Date: April 1, 2013
> >> IETF LC End Date: April 10, 2013
> >> IESG Telechat date: May 16, 2013
> >>
> >> Summary: Ready with nits (that border on minor issues)
> >>
> >> This update improved the readability significantly, and addressed my
> >> major concern about being able to build a list of the gaps. Thank you.
> >>
> >> There are a few issues from my last call review that are still not
> >> addressed.
> >> I have left the classification of minor issue vs nits the same as the
> >> original review to make referring to the earlier review easier,
> >> but please consider all of these Nits. The IESG will need to decide
> >> whether to escalate them.
> >>
> >> I've trimmed away the points that were addressed.
> >>
> >> On 4/1/13 3:46 PM, Robert Sparks wrote:
> >>> --
> >>> Minor issues:
> >>>
> >>> The document currently references
> >>> draft-chown-v6ops-renumber-thinkabout several times.
> >>> That document is long expired (2006). It would be better to simply
> >>> restate what is
> >>> important from that document here and reference it only once in the
> >>> acknowlegements
> >>> rather than send the reader off to read it.
> >> This version still references that long expired draft. There was also
> >> conversation on apps-discuss
> >> about making that reference normative. IMHO, this is not the right way
> >> to treat the RFC series, and
> >> strongly encourage moving the text that you want to reference into
> >> something that will
> >> become an RFC.
> > [Bing] Maybe Brian's suggestion of putting some texts into an appendix is a
> good way. We'll discuss this problem when make the next time update.
> >
> >>> Should section 8 belong to some other document? It looks like
> >>> operational renumbering
> >>> advice/considerations, but doesn't seem to be exploring renumbering
> >>> gaps, except for
> >>> the very short section 8.2 which says "we need a better mechanism"
> >>> without much explanation.
> >> Afaict, this wasn't addressed at all. In particular, "we need a better
> >> mechanism" is still all that
> >> section 8.2 says.
> > [Bing] Sorry for leaving it out. Will do in next update.
> >
> >>> Section 5.1, first bullet. The list below "the impact of ambiguous M/O
> >>> flags" says things like
> >>> "there is no standard" and "it is unspecified". I think you are trying
> >>> to say that there is
> >>> ambiguity in what's written, not that nothing's written. This entire
> >>> list would benefit from
> >>> being recast in terms of what needs to be done (what are the gaps?).
> >> This text remains unmodified.
> > [Bing] We made revision focusing on explaining "what are the gaps", but
> the texts change was omitted, will do in next update.
> >
> >>> --
> >>> Nits/editorial comments:
> >>>
> >>> There are a few sentences ending with "etc." in the document. Please
> >>> consider deleting the
> >>> word from the list - it doesn't help each sentence make its point.
> >> There were some changes, but mostly these still exist. I'll leave
> >> pressing this point further to the RFC Editor.
> > [Bing] A professional language/editorial check would be helpful.
> >
> >>> Sec

Re: Last Call: (The Internet Numbers Registry System) to Informational RFC

[Tom Vest]

On May 11, 2013, at 7:34 PM, SM wrote:

> At 13:08 11-05-2013, Tom Vest wrote:
>> Sorry, but unless you can point to some relevant real-world examples of 
>> self-executing, self-sustaining principles, or you're a nihilist and don't 
>> really believe that such things as principles exist at all, this is a 
>> patently false, bordering on nonsense statement.
> 
> I am not suggesting any self-executing or self-sustaining principles.

Fair enough; I will assume that we agree that "policies" and "principles" are 
not mutually exclusive and incompatible phenomena, and that the class of 
durable, self-executing, and self-sustaining principles is an empty set.

>> One is tempted to ask "work for who?" but that would entail giving this 
>> statement more credence that it merits. Since TCP/IP is only useful to the 
>> end of communication between two or more nodes, the proposed "principle" of 
>> finitude would perfectly consistent with this, and almost every other IETF 
>> addressing/attachment protocol *not* working at all.
>> 
>> Or did you mean to say that "The principle for the above is to avoid set any 
>> constraint unless it is necessary for IETF protocols to 'work' between two 
>> virtual machines, under lab conditions"?
> 
> What I meant was to leave policy (PDP, etc.) to the communities interested in 
> IP addressing.  I'll quote part of a message posted on the thread:
> 
>  'To date, the communities interested in IP addressing have established 
> policies
>   that dictate "operational needs" should be the primary constraint (as 
> opposed
>   to say constraining on geo-political boundaries, by ability to pay, etc).'
> 
> The message is at 
> http://www.ietf.org/mail-archive/web/ietf/current/msg79200.html in case what 
> I was quoted is misrepresented.

I certainly did not intend to misrepresent your position. But given the fact 
that the "part of a message" that you reproduced was offered in response to 
doubts that you yourself raised about the points covered therein (esp. 
"operational need"), what is your position, exactly? As David said, "to date" 
the communities have established policies that are broadly informed by the 
practical implications of the finitude and uniqueness constraints on address 
resource management. However, to conclude based on past observations that such 
will always be true would be tantamount to claiming that management of those 
constraints is assured by the operation of (unspecified self-executing, 
self-sustaining) principles. Based on your views as expressed in/around 
draft-moonesamy-rfc2050-historic-00, it's pretty clear that you don't see any 
durable, much less "timeless" principles embodied therein -- but that only 
makes your position on these matters all the more ambiguous. 

Perhaps it would help if you would answer the following clarifying questions:

1. Is it your position that some other force or principle(s) outside of the 
general mechanisms/practices documented in RFC2050 (and potentially, 
RFC2050-bis) guarantees that IETF-defined addressing protocols will "just work" 
as designed, in perpetuity, and thus the informational codification of matters 
related to the management of finitude and uniqueness constraints is at best 
unnecessary, at worst counterproductive? If so, what are those unnamed 
forces/principles, exactly?

2. Is it your position that, if the traditional "communities interested in IP 
addressing" one day elect to adopt policies that make it impossible for IETF 
addressing protocols to fulfill even the basic "just work" test, then from the 
"IETF view"  that should be regarded as a perfectly appropriate and acceptable 
outcome?

> At 13:14 11-05-2013, Brian E Carpenter wrote:
>> It's up to the IETF to set boundary conditions for the address space
>> that it created (in the case of IPv6) or inherited (in the case of
>> IPv4), in order to protect the long-term viability of the Internet.
> 
> There is some text about Internet address architecture.  It would cover that 
> if the relevant communities are agreeable to it.

Could you please clarify which passages about Internet address architecture you 
are suggesting are sufficient to make the sections about distribution and 
uniqueness constraints unnecessary?

Thanks, 

TV


> Regards,
> -sm 

Re: Last Call: (The Internet Numbers Registry System) to Informational RFC

[Tom Vest]

On May 11, 2013, at 11:17 AM, SM wrote:

> If it's a policy it cannot be a principle.

Sorry, but unless you can point to some relevant real-world examples of 
self-executing, self-sustaining principles, or you're a nihilist and don't 
really believe that such things as principles exist at all, this is a patently 
false, bordering on nonsense statement.

> I'll suggest alternative text:
> 
>  1) Allocation Pool: IP addresses and AS numbers are fixed length numbers.
> The allocation pools for these number resources are considered as
> resources which are finite.
> 
> The principle for the above is to avoid set any constraint unless it is 
> necessary for IETF protocols to work.

One is tempted to ask "work for who?" but that would entail giving this 
statement more credence that it merits. Since TCP/IP is only useful to the end 
of communication between two or more nodes, the proposed "principle" of 
finitude would perfectly consistent with this, and almost every other IETF 
addressing/attachment protocol *not* working at all. 

Or did you mean to say that "The principle for the above is to avoid set any 
constraint unless it is necessary for IETF protocols to 'work' between two 
virtual machines, under lab conditions"? 

I suggest that the proposed alternative text should be rejected.

>> True. The document is documenting current practices and policies. At this 
>> point in time, I'm unaware of a global privacy practice or policy that is 
>> applicable to all levels of the Internet Numbers Registry System.
>> 
>> > Is it up to the IETF to set up a one-stop shop for personal data requests?
>> 
>> I suspect not, but I suspect it isn't up to the IETF to dictate global 
>> privacy policy either.
> 
> Section 2 is about the goals for distributing number resources (re. first 
> sentence).  I suggest removing the third goal as it might be a matter of 
> global (or other) policy.  

Since uniqueness is a basic constraint for most if not all current 
addressing/attachment-related IETF protocols -- even between two virtual 
machines, under lab conditions -- and would still be a basic constraint even if 
current address protocols were not quantity constrained in any way, you seem to 
be suggesting that the IETF forego not only policy statements, but also your 
own "only work" principle, at least under certain circumstances. 

Bottom line: this word "principle," I do not think it means what you think it 
means. 

I suggest leaving section three in place.

TV 






> Regards,
> -sm 

Re: Gen-art telechat review: draft-ietf-6renum-gap-analysis-06.txt (updated for -07)

[Stig Venaas]

On 5/10/2013 8:12 AM, Robert Sparks wrote:

Thanks Bing -

The updates make the document better, and I appreciate the resolution of
referencing Tim's expired draft.


So the solution is to not reference it? I see the name of the draft is
mentioned in the acknowledgments as:
 [draft-chown-v6ops-renumber-thinkabout].

Shouldn't it then be an informational reference? It doesn't make sense
to me to mention a draft in the text and not have a reference.

Stig

Re: [Gen-art] Review: draft-ietf-netmod-rfc6021-bis-01

[Andy Bierman]

On Fri, May 10, 2013 at 7:37 AM, Joel M. Halpern wrote:

> I am guessing that the authors intended the addition of the text
> emphasizing that the no-zone typedefs are derived general typedef addresses
> the difference in the patterns.
>
> Is there a YANG rule that says tat if typedef X is derived from typedef Y
> then the string for X must match the pattern for X and the pattern for Y?
>  If so, then my concern below is misplaced.  (The fact that I find the
> vague pattern for the child misleading is not a fault with the document,
> but rather in my head, under that requirement.)
>

Yes. RFC 6020, sec. 9.4.6.
All the patterns are ANDed together.


>
> Yours,
> Joel
>
>

Andy


> On 4/19/2013 6:24 PM, Joel M. Halpern wrote:
>
>> I am the assigned Gen-ART reviewer for this draft. For background on
>> Gen-ART, please see the FAQ at
>>
>> 
>> >.
>>
>> Please resolve these comments along with any other Last Call comments
>> you may receive.
>>
>> Document: draft-ietf-netmod-rfc6021-bis-**01
>>  Common YANG Data Types
>> Reviewer: Joel M. Halpern
>> Review Date: 19-April-2013
>> IETF LC End Date: 1-May-2013
>> IESG Telechat date: N/A
>>
>> Summary: This document is nearly ready for publication as a Standards
>> Track RFC
>>
>> Major issues:
>>  (The following may well be a non-issue.)
>>  In the revision of the ietf-inet-types, the patterns for the new
>> ip4-address-no-zone and ipv6-address-no-zone are drastically simplified
>> from the ipv4-address and ipv6-address patterns.  The new
>> ipv4-address-no-zone allows any sequence of decimal digits an periods,
>> while the original was carefully defined as dotted quads of 0..255.
>> Similarly, te ipv6-address-no-zone allows any arbitrary sequence of hex
>> digits and colons.  The original patterns were very careful to match
>> rules for validity.  Is there a reason for the change.
>>
>> Minor issues:
>>
>> Nits/editorial comments:
>> __**_
>> Gen-art mailing list
>> gen-...@ietf.org
>> https://www.ietf.org/mailman/**listinfo/gen-art
>>
>>

Re: [Gen-art] Review: draft-ietf-netmod-rfc6021-bis-01

[Joel M. Halpern]

Thank you Juergen.  I see that the pattern statement is therefore correct.
And presumably it is a judgment call as to hw to write te new pattern to 
restrict the old one.  Personally, I find a pattern statement that 
covers a whole lot of other things, but that happens when combined with 
the parent patter to give the right result, to be a confusing way to 
document what is needed.  But I can not claim it is technically 
incorrect.  (And I suppose that some would claim that repeating the more 
detailed parent pattern is redundant.)


Yours,
Joel

On 5/13/2013 6:37 AM, Juergen Schoenwaelder wrote:

Joel,

this is specified in the third paragraph of section 9.4.6 of RFC 6020:

9.4.6.  The pattern Statement

The "pattern" statement, which is an optional substatement to the
"type" statement, takes as an argument a regular expression string,
as defined in [XSD-TYPES].  It is used to restrict the built-in type
"string", or types derived from "string", to values that match the
pattern.

If the type has multiple "pattern" statements, the expressions are
ANDed together, i.e., all such expressions have to match.

If a pattern restriction is applied to an already pattern-restricted
type, values must match all patterns in the base type, in addition to
the new patterns.

/js

On Mon, May 13, 2013 at 12:33:37PM +0200, Benoit Claise wrote:

Forwarding to the authors and WG

Regards, Benoit

I am guessing that the authors intended the addition of the text
emphasizing that the no-zone typedefs are derived general typedef
addresses the difference in the patterns.

Is there a YANG rule that says tat if typedef X is derived from
typedef Y then the string for X must match the pattern for X and
the pattern for Y?  If so, then my concern below is misplaced.
(The fact that I find the vague pattern for the child misleading
is not a fault with the document, but rather in my head, under
that requirement.)

Yours,
Joel

On 4/19/2013 6:24 PM, Joel M. Halpern wrote:

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-netmod-rfc6021-bis-01
 Common YANG Data Types
Reviewer: Joel M. Halpern
Review Date: 19-April-2013
IETF LC End Date: 1-May-2013
IESG Telechat date: N/A

Summary: This document is nearly ready for publication as a Standards
Track RFC

Major issues:
 (The following may well be a non-issue.)
 In the revision of the ietf-inet-types, the patterns for the new
ip4-address-no-zone and ipv6-address-no-zone are drastically simplified

>from the ipv4-address and ipv6-address patterns.  The new

ipv4-address-no-zone allows any sequence of decimal digits an periods,
while the original was carefully defined as dotted quads of 0..255.
Similarly, te ipv6-address-no-zone allows any arbitrary sequence of hex
digits and colons.  The original patterns were very careful to match
rules for validity.  Is there a reason for the change.

Minor issues:

Nits/editorial comments:
___
Gen-art mailing list
gen-...@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review: draft-ietf-netmod-rfc6021-bis-01

[Juergen Schoenwaelder]

Joel,

this is specified in the third paragraph of section 9.4.6 of RFC 6020:

9.4.6.  The pattern Statement

   The "pattern" statement, which is an optional substatement to the
   "type" statement, takes as an argument a regular expression string,
   as defined in [XSD-TYPES].  It is used to restrict the built-in type
   "string", or types derived from "string", to values that match the
   pattern.

   If the type has multiple "pattern" statements, the expressions are
   ANDed together, i.e., all such expressions have to match.

   If a pattern restriction is applied to an already pattern-restricted
   type, values must match all patterns in the base type, in addition to
   the new patterns.

/js

On Mon, May 13, 2013 at 12:33:37PM +0200, Benoit Claise wrote:
> Forwarding to the authors and WG
> 
> Regards, Benoit
> >I am guessing that the authors intended the addition of the text
> >emphasizing that the no-zone typedefs are derived general typedef
> >addresses the difference in the patterns.
> >
> >Is there a YANG rule that says tat if typedef X is derived from
> >typedef Y then the string for X must match the pattern for X and
> >the pattern for Y?  If so, then my concern below is misplaced.
> >(The fact that I find the vague pattern for the child misleading
> >is not a fault with the document, but rather in my head, under
> >that requirement.)
> >
> >Yours,
> >Joel
> >
> >On 4/19/2013 6:24 PM, Joel M. Halpern wrote:
> >>I am the assigned Gen-ART reviewer for this draft. For background on
> >>Gen-ART, please see the FAQ at
> >>
> >>.
> >>
> >>Please resolve these comments along with any other Last Call comments
> >>you may receive.
> >>
> >>Document: draft-ietf-netmod-rfc6021-bis-01
> >> Common YANG Data Types
> >>Reviewer: Joel M. Halpern
> >>Review Date: 19-April-2013
> >>IETF LC End Date: 1-May-2013
> >>IESG Telechat date: N/A
> >>
> >>Summary: This document is nearly ready for publication as a Standards
> >>Track RFC
> >>
> >>Major issues:
> >> (The following may well be a non-issue.)
> >> In the revision of the ietf-inet-types, the patterns for the new
> >>ip4-address-no-zone and ipv6-address-no-zone are drastically simplified
> >>from the ipv4-address and ipv6-address patterns.  The new
> >>ipv4-address-no-zone allows any sequence of decimal digits an periods,
> >>while the original was carefully defined as dotted quads of 0..255.
> >>Similarly, te ipv6-address-no-zone allows any arbitrary sequence of hex
> >>digits and colons.  The original patterns were very careful to match
> >>rules for validity.  Is there a reason for the change.
> >>
> >>Minor issues:
> >>
> >>Nits/editorial comments:
> >>___
> >>Gen-art mailing list
> >>gen-...@ietf.org
> >>https://www.ietf.org/mailman/listinfo/gen-art
> >>
> >
> >
> 

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103 

Re: [Gen-art] Review: draft-ietf-netmod-rfc6021-bis-01

[Benoit Claise]

Forwarding to the authors and WG

Regards, Benoit
I am guessing that the authors intended the addition of the text 
emphasizing that the no-zone typedefs are derived general typedef 
addresses the difference in the patterns.


Is there a YANG rule that says tat if typedef X is derived from 
typedef Y then the string for X must match the pattern for X and the 
pattern for Y?  If so, then my concern below is misplaced. (The fact 
that I find the vague pattern for the child misleading is not a fault 
with the document, but rather in my head, under that requirement.)


Yours,
Joel

On 4/19/2013 6:24 PM, Joel M. Halpern wrote:

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-netmod-rfc6021-bis-01
 Common YANG Data Types
Reviewer: Joel M. Halpern
Review Date: 19-April-2013
IETF LC End Date: 1-May-2013
IESG Telechat date: N/A

Summary: This document is nearly ready for publication as a Standards
Track RFC

Major issues:
 (The following may well be a non-issue.)
 In the revision of the ietf-inet-types, the patterns for the new
ip4-address-no-zone and ipv6-address-no-zone are drastically simplified
from the ipv4-address and ipv6-address patterns.  The new
ipv4-address-no-zone allows any sequence of decimal digits an periods,
while the original was carefully defined as dotted quads of 0..255.
Similarly, te ipv6-address-no-zone allows any arbitrary sequence of hex
digits and colons.  The original patterns were very careful to match
rules for validity.  Is there a reason for the change.

Minor issues:

Nits/editorial comments:
___
Gen-art mailing list
gen-...@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review: draft-ietf-netmod-rfc6021-bis-01

[Benoit Claise]

Forwarding to the authors and WG

Regards, Benoit

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-netmod-rfc6021-bis-01
Common YANG Data Types
Reviewer: Joel M. Halpern
Review Date: 19-April-2013
IETF LC End Date: 1-May-2013
IESG Telechat date: N/A

Summary: This document is nearly ready for publication as a Standards 
Track RFC


Major issues:
(The following may well be a non-issue.)
In the revision of the ietf-inet-types, the patterns for the new 
ip4-address-no-zone and ipv6-address-no-zone are drastically 
simplified from the ipv4-address and ipv6-address patterns.  The new 
ipv4-address-no-zone allows any sequence of decimal digits an periods, 
while the original was carefully defined as dotted quads of 0..255. 
Similarly, te ipv6-address-no-zone allows any arbitrary sequence of 
hex digits and colons.  The original patterns were very careful to 
match rules for validity.  Is there a reason for the change.


Minor issues:

Nits/editorial comments: