> On Mar 7, 2019, at 17:50, Elwyn Davies wrote:
>
> Hi, Christian.
>
> Thanks for the quick response.
>
> I understand your intent, but the intent and the specification appear to be
> in conflict.
>
> The pattern for tags is
> pattern '[a-zA-Z_][a-zA-Z0-9-_]*:[S ]+';
>
> This RE
[to this thread in general, not anyone in particular]
We have done this work over 2 years in the working group. It has been presented
multiple times with multiple revisions etc. We have arrived at a solution that
works, and has cleared WG LC, and IETF LC.
We have a process we need to follow it.
In that case, why not make it so the tags are actually valid URIs, similar to
XML namespaces?
From: netmod on behalf of William Lupton
Sent: Friday, 8 March 2019 7:37 a.m.
To: Andy Bierman
Cc: Datatracker on behalf of Elwyn Davies; IETF discussion list; NetMod
Reviewer: Joel Halpern
Review result: Almost Ready
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more inf
Hi, Christian.Thanks for the quick response.I understand your intent, but the
intent and the specification appear to be in conflict.The pattern for tags is
pattern '[a-zA-Z_][a-zA-Z0-9-_]*:[S ]+'; This REQUIRES two
character strings separated by a colon unless I have totally forgot
Hi all,
The following reviewers have assignments:
For telechat 2019-03-14
Reviewer Type LC end Draft
Jari Arkko Telechat 2018-12-24 draft-ietf-6lo-nfc-13 *
Christer Holmberg Telechat 2019-02-17
draft-ietf-kitten-pkinit-alg-agility-06 *
For telechat 201
18.txt
Reviewer: Francis Dupont
Review Date: 20190228
IETF LC End Date: 20190307
IESG Telechat date: unknown
Summary: Ready
Major issues: None
Minor issues: None
Nits/editorial comments:
- ToC page 3 and 7 page 20: Acknowledgements -> Acknowledgments
- 1 page 3: RFC8402 -> [RFC8402]
On Thu, Mar 07, 2019 at 02:02:39PM -0500, Christian Hopps wrote:
>
> We already have a reviewed and approved prefixes registry.
>
> Given nothing is broken here, and the current solution has been reviewed for
> 2+ years, and with careful consideration approved by the working group, this
> does
We already have a reviewed and approved prefixes registry.
Given nothing is broken here, and the current solution has been reviewed for 2+
years, and with careful consideration approved by the working group, this does
not seem like change that should be considered (or perhaps even suggested) a
On Thu, Mar 7, 2019 at 10:42 AM Christian Hopps wrote:
>
> Andy Bierman writes:
>
> > I strongly agree that a prefix SHOULD be present, not MUST be present.
> > I also think the 3 standard prefixes will be insufficient over time.
> > (Having every organization on the planet except IETF share the
On Thu, Mar 7, 2019 at 10:37 AM William Lupton
wrote:
> This remark might be out of context (I haven't been following the details)
> but this reference to prefixes makes me wonder whether there's any way that
> registered URN namespaces could be regarded as valid prefixes.
> https://www.iana.org/
Andy Bierman writes:
I strongly agree that a prefix SHOULD be present, not MUST be present.
I also think the 3 standard prefixes will be insufficient over time.
(Having every organization on the planet except IETF share the prefix
"vendor:"
seems a bit short-sighted)
Sounds like you are a st
This remark might be out of context (I haven't been following the details)
but this reference to prefixes makes me wonder whether there's any way that
registered URN namespaces could be regarded as valid prefixes.
https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml
On Thu, 7 Mar 2
On Wed, Mar 6, 2019 at 2:51 PM Christian Hopps wrote:
> Thanks for the review! Comments inline.
>
> > On Mar 5, 2019, at 7:26 PM, Datatracker on behalf of Elwyn Davies <
> ietf-secretariat-re...@ietf.org> wrote:
> >
> > Reviewer: Elwyn Davies
> > Review result: Almost Ready
> >
>
> > If I re
tps://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-spring-segment-routing-mpls-18.txt
Reviewer: Francis Dupont
Review Date: 20190228
IETF LC End Date: 20190307
IESG Telechat date: unknown
Summary: Ready
Major issues: None
Minor issues: None
Nits/editorial comments:
- ToC page 3 and 7 p
Re-,
I hear you,
Cheers,
Med
> -Message d'origine-
> De : Roni Even (A) [mailto:roni.e...@huawei.com]
> Envoyé : jeudi 7 mars 2019 13:29
> À : BOUCADAIR Mohamed TGI/OLN; Datatracker on behalf of Roni Even; gen-
> a...@ietf.org
> Cc : draft-ietf-dots-data-channel@ietf.org; i...@ietf
Hi Med,
Thanks I am OK with your response only open one
> administrator even if rejected.
[Med] This is deployment-specific. For example, if conflict handling requires
"notify an administrator for validation", there is no point to report again.
[RE] Yes but for example "reject all" may cause a
Hi Roni,
Thank you for the review.
Please see inline.
Cheers,
Med
> -Message d'origine-
> De : Datatracker on behalf of Roni Even [mailto:nore...@ietf.org]
> Envoyé : jeudi 7 mars 2019 11:21
> À : gen-art@ietf.org
> Cc : draft-ietf-dots-data-channel@ietf.org; i...@ietf.org; d...@i
Reviewer: Roni Even
Review result: Ready with Nits
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more inf
19 matches
Mail list logo